Follow up the other post from today.
First of all, the gimp-print patch is now committed in portage, so you just need to sync and if you are using –as-needed it will emerge just fine. There’s still something that is not really “clean”, as one of the binaries built by it links to the library installed in the system, but that’s not related to –as-needed and I left it out for now.
wxGTK and aMule are still not fixed. While aMule built the first try, it didn’t start. Now wxGTK builds, but then anything fails to link against it because of undefined references. And yes, I’ve filtered –as-needed from both wxGTK and aMule. That is going to be a looong standing problem for now.
Other than that, I’ve yet to see something else failing today, so it’s a quite interesting result for now. To be safe, I’m currently finishing building my whole system using –as-needed. I used a few tricks to get the packages I’ve already rebuilt in the past two days so that I don’t have to rebuild them. It’s still an impressive emerge: almost 500 packages! Many of them are modular x, tho.. it would be interesting to see how modular x will behave with that.
metalog failed, but I’m not sure if it’s related to –as-needed as it fails with a compiler, rather than linker, error in configure.
Update: okay, metalog’s failure is totally unrelated to –as-needed, it was rather a problem with confcache. I’ll see to fix that after all this emerge is done.
Update 2: Sebastian sent me a list of gnome packages that fails to link with –as-needed, I’ll give them a look in a chroot and see what I can do to fix them. Usually the fixes are simple, it’s not the case of libww, that I’ve just given up fixing. The problem is that libwww defines a lot of small libraries interdependent without setting the dependencies. I’ve given up for now fixing it, but the fixes are possible. It just requires more time that I have right now. I have a patch for net-snmp but I have to test it first.
And as I promised some misc news, not related to –as-needed… first of all I want to thanks the PaX Team for providing fixes for TEXTREL problems with xine-lib’s and vlc’s win32codecs loaders, now they should be both fine with that. This does not mean that xine-lib is 100% TEXTREL free yet, but we’re approaching it. I also got a patch for libdts, but if you’re having trouble with that, simply rebuild it, I didn’t want to revbump it but it’s now fixed for x86 and builds with PIC (by using libtool correctly).
Then from the KDE herd view, I have committed a change to kde eclass that I had prepared a while back and discussed in kde@g.o alias for a couple of weeks. Basically now the kdeenablefinal flag does not appear on all and every KDE-based package on the tree, but only for all the packages in kde-base (because they all support it) and if the package defines kdeenablefinal in the IUSE by itself (as amarok ebuild now does). This does not mean that you’re going to lose kdeenablefinal on the packages that doesn’t have the useflag anymore, because before it was simply being ignored by all the packages not in kde-base; this time instead if a package supports it (like amarok) it will actually be used!
And to close this entry, the system rebuild will also show me how much space is required to have a -g3 compiled system with splitdebug, currently I have 5.7GB of /usr/lib/debug directory.
I wonder where can be the know-how be found (documentation, resources, anything) on how to actually get rid of text relocations. I can mostly only find explanations on what a text relocation is, why it’s bad, how to locate the source, and how to get rid of it given asm code. Nothing about possible causes and fixes in case of higher languages, such as C, or in my case C++ with using a templated iostream in a certain way (TEXTREL in wxGTK, btw).
for metalog: maybe in configure it tries to link and “hello world” using some libs that are messed up.
diego, wonderful work…i wonder if you can write a Gentoo Documentation document, a sort of howto with explainations and so on..
Mart, I don’t have a clue about that, it’s something I tried to find myself, and at the end I just gave up to accept it as a dogma :|Are you sure you’re using PIC mode for the shared libraries (-fPIC), and there’s no -fprefer-non-pic somewhere (libtool uses it).Patrizio, metalog failure was due to confcache at the end, I’ve found out by trying it by hand 🙂 about documentation… well it’s still an unsupported feature right now, I’d have to make sure that it doesn’t break users’ systems (atm I’m sure of the opposite for most cases :P). I’ll see to write something unofficial in my dev space lately or on the unsupported forums, we’ll see 🙂
Yeah, I’m sure -fPIC is included. I’ve been compiling the file in question by hand too from commandline.-fPIC -DPIC -D__PIC__ is in there.Basically,(*m_ostr)
Wonder how posting less than signs for C++ streaming is done here. Lets try.Basically,(*m_ostr) << str << wxConvertWX2MB(szString) << std::endl; causes a TEXTRELModifying it to(*m_ostr) << std::endl; still causes a TEXTREL;m_ostr is a pointer to a std::ostreamThe following doesn’t cause TEXTRELs:(*m_ostr) << str << wxConvertWX2MB(szString);(*m_ostr) << str; (*m_ostr).flush();(*m_ostr).clear()Weird stuff. I suppose need to add std::endl; differently, maybe just through n + flush. But I can’t understand why.This isn’t the only TEXTREL. All seemed to appear around the time std iostream’s were put to usage.
Well, I think the wxGTK problem is mainly due to the combination of -fvisibility-inlines-hidden and –as-needed. Diego, do you use -fvisibility-inline-hidden, too? I posted some more details on http://bugs.gentoo.org/show…