[Bug 829002] New: devel:tools:building/site-config: 64-bit builds incorrectly link 32bit-libs; libtool.m4's 'sys_lib_dlsearch_path_spec' incorrectly defined
https://bugzilla.novell.com/show_bug.cgi?id=829002 https://bugzilla.novell.com/show_bug.cgi?id=829002#c0 Summary: devel:tools:building/site-config: 64-bit builds incorrectly link 32bit-libs; libtool.m4's 'sys_lib_dlsearch_path_spec' incorrectly defined Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: Other URL: https://forums.opensuse.org/english/other-forums/devel opment/open-build-service-obs/488586-64-bit-build-fwiw -vlc-incorrectly-links-32bit-libs-help-troubleshooting -sys_lib_dlsearch_path.html#post2571029 OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: 3rd party software AssignedTo: sbrabec@suse.com ReportedBy: darx+opensuse@sent.com QAContact: opensuse-communityscreening@forge.provo.novell.com CC: pth@suse.com Found By: Community User Blocker: --- When building various packages (e.g. VLC, libva, etc) on 64-bit Opensuse 12.3/Factory, autofoo config incorrectly links in libs from Opensuse's 32-bit lib paths (/usr/lib). This appears to be a result of "sys_lib_dlsearch_path_spec" being incorrectly determined/set, e.g. grep sys_lib_dlsearch_path_spec config.status sys_lib_dlsearch_path_spec='/lib /usr/lib /usr/local/lib64 /usr/lib64 /usr/local/lib /usr/lib' Obviously, on a 64-bit system, those "/lib /usr/lib" shouldn't be included in the search path. Or at least not 1st in order. Iiuc, that value stems from /usr/share/aclocal/libtool.m4 , sourced by "site-config" pkg. Here's a link to a post where I first saw this crop up: https://forums.opensuse.org/english/other-forums/development/open-build-serv... And another link to other/related sightings (I think) in the wild: http://www.archivum.info/bug-libtool@gnu.org/2010-01/00061/sys_lib_dlsearch_... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=829002 https://bugzilla.novell.com/show_bug.cgi?id=829002#c1 Stanislav Brabec <sbrabec@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #1 from Stanislav Brabec <sbrabec@suse.com> 2013-07-11 15:24:12 CEST --- I am not sure, whether it is a bug of site-config, but it it is triggered by site-config for sure. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=829002 https://bugzilla.novell.com/show_bug.cgi?id=829002#c2 --- Comment #2 from darx suse <darx+opensuse@sent.com> 2013-07-11 17:00:42 UTC --- It seems that quite a few packages handle arch-specific $libdir fairly poorly. In the numerous chats I've had with upstreams, the 'blame' almost always is placed on *suse -- "your install/distro is broken" etc etc. I think it's BS, and very much prefer the libdir separation that we use, but getting all upstreams to add correct conditional handling for linking search paths to their src is not realistically going to happen. Whether or not it really is a "bug" in site-config, it would be useful to find the root cause and "fix" it for *suse instances. Ideally, a fix would get pushed to upstream -- somewhere. autoconf maybe? libtool? If not, I think *suse-specific site-config pkg is the right place. But, tbh, I'm still not sure "where" this issue belongs. I'm digging in autofoo docs trying to figure out what really comes 1st ... between that and reading through these packages' configure.ac, etc autofoo stuff, it's a bit of a mess. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=829002 https://bugzilla.novell.com/show_bug.cgi?id=829002#c3 Stanislav Brabec <sbrabec@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |darx+opensuse@sent.com --- Comment #3 from Stanislav Brabec <sbrabec@suse.com> 2013-07-12 21:57:31 CEST --- Could you try following change? Open /usr/share/site/x86_64-unknown-linux-gnu Find following command: if test "x$ac_config_site_cross_to_32bit_host" = xNONE; then ac_config_site_64bit_host=YES fi And change it to: if test "x$ac_config_site_cross_to_32bit_host" = xNONE; then ac_config_site_64bit_host=YES lt_cv_sys_lib_dlsearch_path_spec="/lib64 /usr/lib64" fi I guess that it will work-around your problem. It changes the default, but in my opinion it is an ugly hack. lt_cv_sys_lib_dlsearch_path_spec is a variable intended for use in config.cache if configure is called with -C. I will try to search something better. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=829002 https://bugzilla.novell.com/show_bug.cgi?id=829002#c4 darx suse <darx+opensuse@sent.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|darx+opensuse@sent.com | --- Comment #4 from darx suse <darx+opensuse@sent.com> 2013-07-12 22:28:02 UTC --- doesn't work here :-/ with ls -al /usr/lib*/libGL.* -rw-r--r-- 1 root root 654 Jul 6 17:00 /usr/lib64/libGL.la lrwxrwxrwx 1 root root 10 Jul 6 17:00 /usr/lib64/libGL.so -> libGL.so.1* lrwxrwxrwx 1 root root 15 Jul 6 17:00 /usr/lib64/libGL.so.1 -> libGL.so.319.23* -rwxr-xr-x 1 root root 1.1M Jul 6 17:00 /usr/lib64/libGL.so.319.23* lrwxrwxrwx 1 root root 10 Jul 10 23:28 /usr/lib/libGL.so -> libGL.so.1* lrwxrwxrwx 1 root root 15 Jul 8 12:04 /usr/lib/libGL.so.1 -> libGL.so.319.23* -rwxr-xr-x 1 root root 965K Jul 6 17:00 /usr/lib/libGL.so.319.23* building one of the 'culprit' apps, here: libva ./configure make ... /usr/lib/libGL.so: could not read symbols: File in wrong format collect2: error: ld returned 1 exit status ... checking grep ^sys_lib_dlsearch_path_spec libtool sys_lib_dlsearch_path_spec="/lib /usr/lib /usr/local/lib64 /usr/lib64 /usr/local/lib /usr/lib /usr/lib64/xorg/modules " mod'ing vi /usr/share/site/x86_64-unknown-linux-gnu ... if test "x$ac_config_site_cross_to_32bit_host" = xNONE; then ac_config_site_64bit_host=YES + lt_cv_sys_lib_dlsearch_path_spec="/lib64 /usr/lib64" fi ... make clean ./configure make ... /usr/lib/libGL.so: could not read symbols: File in wrong format collect2: error: ld returned 1 exit status ... grep ^sys_lib_dlsearch_path_spec libtool sys_lib_dlsearch_path_spec="/lib /usr/lib /usr/local/lib64 /usr/lib64 /usr/local/lib /usr/lib /usr/lib64/xorg/modules " libtoolize-ing libtoolize --copy --force libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' make clean ./configure make ... /usr/lib/libGL.so: could not read symbols: File in wrong format collect2: error: ld returned 1 exit status ... grep ^sys_lib_dlsearch_path_spec libtool sys_lib_dlsearch_path_spec="/lib /usr/lib /usr/local/lib64 /usr/lib64 /usr/local/lib /usr/lib /usr/lib64/xorg/modules " ok, so full reconf, autoreconf --install --force make clean ./configure make ... /usr/lib/libGL.so: could not read symbols: File in wrong format collect2: error: ld returned 1 exit status ... grep ^sys_lib_dlsearch_path_spec libtool sys_lib_dlsearch_path_spec="/lib /usr/lib /usr/local/lib64 /usr/lib64 /usr/local/lib /usr/lib /usr/lib64/xorg/modules " it's still 'something else'. will dig some more in a bit. i need to map out what happens in what order, for myself ... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com