portage always strips everything including shared objects which is a major problem. If you strip an so you prevent dlloading, which is commonly used in many applications. I encounter this all the time, and i usually just end up editing the ebuild and maintaining an overlay directory. This, of course, becomes to much of a pain to maintain, so I have pretty much had to disable stripping all together (using FEATURES). Here is the most recent example I have encountered of the problem. The subversion JNI bindings do not work (libjavasvn) because JNI uses dlload to load the c/c++ portion of the module. Now in the above scenario dlload has to be used because the underlying technology uses it, so you could just keep fixing each individual ebuild. IMO this is a bad solution though because you can not predict how applications will use the library. It is perfectly legitimate for me to write a client application to dlload something (say libncurses), and you have no way of possibly detecting it (except for forcing all dependant libraries to be recompiled). It would be much more sensible to just, by default, not strip libraries. Thanks, -Jason Reproducible: Always Steps to Reproduce: 1. 2. 3.
We strip ET_EXEC and ET_DYN for a reasons already documented in bugzilla. You may edit your system wide strip flags as needed. In my make.conf for an embedded system I use the following. PORTAGE_STRIP_FLAGS="--strip-unneeded -R .note -R .comment" You may for example want to only use PORTAGE_STRIP_FLAGS="-g" The guts to the stripping code used by portage is handled by the /usr/lib/portage/bin/prepstrip shell script. (read it for more info)
dlload() works fine w/stripped libraries so i really have no idea what you're refering to ...
Setting PORTAGE_STRIP_FLAGS fixes my problem, somehow strip was striping dynamic symbols as well, not sure why. Thanks!
