KDE 3.4.3 and -fvisibility-inlines-hidden

Neuro · 2005-10-19 11:27:52

Hi folks,

First of... Arch is great (migrated from Slack ). And yea, it's great that it's optimised for i686 and such

However the KDE packages in Arch are a bit... slow I mean I have a decent (but not a high-end) system (Ath-XP 2500, 512 MB DDR400), but I still had to wait a bit for Konqueror to open (I use it as a file manager, my browser is Firefox).

Now, what I've heard was that -fivisibility-inlines-hidden thingy in gcc 4.0 speeds up C++ applications. Yea, I've heard that these flags are added automagically during ./configure while building KDE, but I've never been able to spot them in gcc compile commands while make'ing.

Thus, I've decided to give it a shot myself and recompile some (since I don't use the rest that often) KDE packages using the following flags:

export CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer"
export CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -fvisibility-inlines-hidden"

And yea.. I know some of you will now say: hey, Arch is not an athlon-xp optimised distro, but a generic 686 one. Yea, I know. But AFAIK the athlon-xp specific optimisations don't have such a big meaning (being SSE, 3dNow and such mostly) to normal aps.

I've recompiled the following packages:

kdelibs
kdebase
kdeutils
kdegraphics

And you know what? I don't have to wait for Konqueror anymore. It opens in a blink of an eye. So does Kpdf with large documents. And yea.. I know these aren't hard numbers but rather impressions...

I'm aware that there has been a discussion regarding these flags before... but I couldn't make out the final outcome of them So, could anyone enlighten me: are the Arch stock KDE package compiled with fvisibility-inslines-hidden already? My guess is no, since when I tried to build KDE using the vanilla PKGBUILDS from ABS, there were no fvisibility flags in the compilation commands invoked by make. Of course I can be wrong, but if the stock packages aren't built with them, mayby they should be?

Also, does anyone have clue why I can't use -fvisibility=hidden with the stock GCC 4.03? During C++ program compilation it says that the -fivisibility=hidden attribute is not recognized. -fvisibility-inlines-hidden worked well.. but that one doesn't. Anyone?[/code]

IceRAM · 2005-10-19 13:37:42

Old topic: link. Might have been forgotten.

tpowa · 2005-10-19 14:30:45

kde checks for these compile flags if it's possible it enables it.
greetings
tpowa

Neuro · 2005-10-19 16:10:04

tpowa wrote:

kde checks for these compile flags if it's possible it enables it.
greetings
tpowa

That's what I've heard too. But while I was compiling KDE using the vanilla PKGBUILD and Arch flags they weren't present in parameters passed to gcc. e It's a bit weird, because AFAIK there is no other way of passing compilation flags.

Also, what's the thingg with -fvisibility=hidden being a wrong parameter in GCC 4.03? Anyone had the same issues? It worked in the patched 3.4

LB06 · 2005-10-19 21:04:20

That's strange. My system is slower than yours: 1.5GHz, 512MB, 4200rpm HDD. Yet konqueror shows up almost immediately. Do you have an instance preloaded? That will speed up konq a lot I guess.

Neuro · 2005-10-20 05:53:13

LB06 wrote:

That's strange. My system is slower than yours: 1.5GHz, 512MB, 4200rpm HDD. Yet konqueror shows up almost immediately. Do you have an instance preloaded? That will speed up konq a lot I guess.

Naaah. I turned that off on purpose to see the difference.

Additionally even with preloading it didn't show up immidietly, although the delay was significantly smaller.

jw · 2006-01-06 10:35:55

I think I have to resurrect this thread. I read this the other day and figured I'd check Neuro's story. Here's what I did:

· I compiled the vanilla kdelibs-3.5.0-6 packages piping standard out & error to a log file
· I then added the following lines to the PKGBUILD

# Hack: make sure fvisibility-inlines-hidden is used
export CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" 
export CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -fvisibility-inlines-hidden"

· I recompiled kdelibs using the new PKGBUILD (without deleting the src/ dir, in order to save some compile time)

The result is clear. If you do a grep fvisibility on the vanilla log, you'll notice that the compile flag is detected by configure, but NOT USED in the build process. A comparison with the fvisibility log shows that the are used when building with the second package build.

Normally I'm a bit sceptical about performance benefits from compile flags. However this flag apparently should make a significant difference. So, TPOWA, if you read this: Can you make sure the flags are used for the next KDE build?

Log files can be downloaded here:
http://www.ilorentz.org/~janwillem/temp … la.log.bz2
http://www.ilorentz.org/~janwillem/temp … ty.log.bz2

Neuro · 2006-01-06 15:30:56

jw wrote:

Normally I'm a bit sceptical about performance benefits from compile flags. However this flag apparently should make a significant difference. So, TPOWA, if you read this: Can you make sure the flags are used for the next KDE build?

Yea, that'd be a good idea I think. Since the standard compiler in Arch is gcc 4.0 and it supports fvisibility by default. Even if the flags are somehow passed to the compiler (the other way, since they aren't pased on the command line), filtering the flags and adding fvisibility wouldn't hurt, would it?

tpowa · 2006-01-07 07:17:11

i think the flags are used when they are possible to use, perhaps kdelibs don't need that flag.
browsed through gentoo ebuild, they don't add it too.
kdesdk claims for if no visibility stuff is there, on arch it doesnT' claim so i think everything is alright.

Neuro · 2006-01-07 08:29:28

tpowa wrote:

i think the flags are used when they are possible to use, perhaps kdelibs don't need that flag.
browsed through gentoo ebuild, they don't add it too.
kdesdk claims for if no visibility stuff is there, on arch it doesnT' claim so i think everything is alright.

Well, but a little sed line in the PKGBUILDs wouldn't hurt in the next release. Just to make sure the packages are compiled with it.

It's not only kdelibs, because I've been compiling kdebase and kdemultimedia also, and the fvisibility flags weren't passed to the compiler on the command line.

Apart from that I'd liek to ask if anyone knows why G++ complains about 'unknown attribute' when I pass

-fvisibility=hidden

or any -fvisibility parameter as an option? It's documented in the man page, so it shoudl work, but it doesn't.

tpowa · 2006-01-07 08:40:48

http://bugs.kde.org/show_bug.cgi?id=111115
coud it be that our stuff is affected by this? --> visibility is not used.

tpowa · 2006-01-07 09:02:43

--enable-gcc-hidden-visibility
will activate it again, will add this to nex 3.51 release in 2 weeks
greetings
tpowa

Neuro · 2006-01-07 09:24:47

tpowa wrote:

--enable-gcc-hidden-visibility
will activate it again, will add this to nex 3.51 release in 2 weeks
greetings
tpowa

Thanks tpowa

jw · 2006-01-07 11:14:21

I did some more reading. Things seem slightly more complicated than I thought. Do I understand the following correctly?

· The -fvisibility-inlines-hidden flag can (and should, i guess) safely be use for any package. As far as I understand it removes library symbols associated with inlined functions. Though safe, this switch probably has a rather minor effect on performance.
· The -fvisibility=hidden switch makes all symbols hidden by default. This causes breakage, unless ALL required symbol have been EXPLICITLY marked as public in the code. This switch can therefore only been enabled if sources have been written to support it.

KDE (to some extent) seems to support the second switch. However it is not clear to me whether -fvisibility=hidden can safely be enabled for ALL kde sources, or just a select number known by the KDE build process.

Tpowa: I do think something is amiss. It seems highly unlikely to me that no sources kdelibs support the -fvisibility=hidden switch. Other packages use these libs intensively, so this would be the first place where one would expect support for it.

I will try a recompile with -fvisibility=hidden to see if anything breaks. That might save you some time.

tpowa · 2006-01-07 11:22:45

you don't need to do it, i built it atm and upload it to testing in the evening it should be ready.
greetings
tpowa

Neuro · 2006-01-07 14:27:50

tpowa wrote:

you don't need to do it, i built it atm and upload it to testing in the evening it should be ready.
greetings
tpowa

Great, I'll test it as soon as it appears in testing.

jw wrote:

I do think something is amiss. It seems highly unlikely to me that no sources kdelibs support the -fvisibility=hidden switch. Other packages use these libs intensively, so this would be the first place where one would expect support for it.

As far as I understand correctly, the bug report tpowa pointed us to says that there were some issues with KDE 3.4.x GCC 4.0.2 and -fvisibility. It was traced back to an issue with a missing visibility declaration somewhere in the STL lib of C++. I've stumbled upon an information that it is fixed in GCC 4.0.3, but if I get the bug info right, since then KDE builds without -fvisibility even if the compiler allows it.

jw · 2006-01-07 14:45:58

Neuro wrote:

As far as I understand correctly, the bug report tpowa pointed us to says that there were some issues with KDE 3.4.x GCC 4.0.2 and -fvisibility. It was traced back to an issue with a missing visibility declaration somewhere in the STL lib of C++. I've stumbled upon an information that it is fixed in GCC 4.0.3, but if I get the bug info right, since then KDE builds without -fvisibility even if the compiler allows it.

Actually, I it seems that our libstdc++ is working properly. My logs for the kdelibs builds show:

checking grepping for visibility push/pop in headers... yes

The test above was added to fix Bug 111115, mentioned by tpowa above. I you look at the configure patch below you'll see that `yes' should indicate that our libstdc++ is handling visibility correctly:

 [ 
    AC_REQUIRE([AC_PATH_QT]) 
   
 +  AC_MSG_CHECKING([grepping for visibility push/pop in headers]) 
 + 
    if test "x$GXX" = "xyes"; then 
 +    AC_LANG_SAVE 
 +    AC_LANG_CPLUSPLUS 
 +    AC_EGREP_CPP( 
 +       [GCC visibility push], 
 +       [ #include <cassert> 
 +       ], 
 +    [ 
 +      AC_MSG_RESULT(yes) 
 +      kde_stdc_visibility_patched=yes ], 
 +    [ 
 +      AC_MSG_RESULT(no) 
 +      AC_MSG_WARN([Your libstdc++ doesn't appear to be patched for 
 +                   visibility support. Disabling -fvisibility=hidden]) 
 + 
 +      kde_stdc_visibility_patched=no ]) 
 +    AC_LANG_RESTORE 
 + 
      kde_have_gcc_visibility=no 
 -    KDE_CHECK_COMPILER_FLAG(fvisibility=hidden, 
 -    [ 
 -      kde_have_gcc_visibility=yes 
 -      CXXFLAGS="$CXXFLAGS -fvisibility=hidden" 
 -      KDE_CHECK_VISIBILITY_GCC_BUG 
 -      HAVE_GCC_VISIBILITY=1 
 -      AC_DEFINE_UNQUOTED(__KDE_HAVE_GCC_VISIBILITY, "$HAVE_GCC_VISIBILITY", [define to 1 if -fvisibility is supported]) 
 -    ]) 
 + 
 +    if test x$kde_stdc_visibility_patched = xyes ; then 
 +      KDE_CHECK_COMPILER_FLAG(fvisibility=hidden, 
 +      [ 
 +        kde_have_gcc_visibility=yes 
 +        CXXFLAGS="$CXXFLAGS -fvisibility=hidden" 
 +        KDE_CHECK_VISIBILITY_GCC_BUG 
 +        HAVE_GCC_VISIBILITY=1 
 +        AC_DEFINE_UNQUOTED(__KDE_HAVE_GCC_VISIBILITY, "$HAVE_GCC_VISIBILITY", [define to 1 if -fvisibility is supported]) 
 +      ]) 
 +    fi 
    fi 
  ])

BTW: I've rebuilt kdelibs with `--enable-gcc-hidden-visibility' and all seems well.

Tpowa: Thanks for looking into this

Neuro · 2006-01-08 15:07:21

Just installed KDE from testing. Everything works fine. Thanks tpowa.

jw · 2006-01-08 23:07:48

Same for me. Cheers tpowa!

pbw · 2006-01-09 11:42:36

All seems good here too, i'm running kdelibs from testing as well.

Neuro · 2006-01-28 12:37:08

Lately I started to have issues with Konqueror. For example I can't visit:
http://www.archlinux.org/pipermail/arch … hread.html
http://www.archlinux.org/pipermail/arch … hread.html
because Konq crashes immediately.

I'm using TESTING. Reported bugs both to KDE and Arch
http://bugs.archlinux.org/task/3829
https://bugs.kde.org/show_bug.cgi?id=120704

Maybe this is somehow related with the move to gcc visibility. Anyone using testing could tell me if they have similar issues? Anyone using current could comment?

tpowa · 2006-01-28 13:24:51

no crashes here it works fine tiwh new qt packge and 3.5.1

Neuro · 2006-01-28 14:37:55

Eh It seems like it's a local bug. I'm running latest KDE 3.5.1, qt and the devel fontconfig. I don't know where I could look for the problem

I tried with a different user and a clean KDE profile, but problem is there too. I don't have time to reinstall my system but... It looks like it might be the only way out

tpowa · 2006-01-28 14:40:25

we patched fontconfig for new qt patch from kde.
perhaps this is your problem.
greetings
tpowa

Arch Linux

#1 2005-10-19 11:27:52

KDE 3.4.3 and -fvisibility-inlines-hidden

#2 2005-10-19 13:37:42

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#3 2005-10-19 14:30:45

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#4 2005-10-19 16:10:04

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#5 2005-10-19 21:04:20

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#6 2005-10-20 05:53:13

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#7 2006-01-06 10:35:55

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#8 2006-01-06 15:30:56

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#9 2006-01-07 07:17:11

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#10 2006-01-07 08:29:28

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#11 2006-01-07 08:40:48

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#12 2006-01-07 09:02:43

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#13 2006-01-07 09:24:47

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#14 2006-01-07 11:14:21

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#15 2006-01-07 11:22:45

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#16 2006-01-07 14:27:50

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#17 2006-01-07 14:45:58

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#18 2006-01-08 15:07:21

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#19 2006-01-08 23:07:48

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#20 2006-01-09 11:42:36

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#21 2006-01-28 12:37:08

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#22 2006-01-28 13:24:51

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#23 2006-01-28 14:37:55

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

#24 2006-01-28 14:40:25

Re: KDE 3.4.3 and -fvisibility-inlines-hidden

Board footer