64-bit build (fwiw, VLC) incorrectly links 32bit-libs; help troubleshooting 'sys_lib_dlsearch_path'

English Open Build Service (OBS)
1

I’m working on a native build of upstream VLC on an Opensuse 12.3/64 box; I’ll eventually package it up in obs for my own use.

My desktop has nvidia drivers installed “The hard way”. That install results in libGL installed as dual-arch:


    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  6 17:00 /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*

If I do a simple build of VLC on/for X86_64:


    git clone git://git.videolan.org/vlc.git
    ./bootstrap
    ./configure \
      --host=x86_64-suse-linux-gnu \
      --build=x86_64-suse-linux-gnu \
      ...
    make

it fails at


        ...
        make[4]: Entering directory
        `/home/dev/vlc-master/modules/video_output'
          CCLD     libgl_plugin.la
        /usr/lib/libGL.so: could not read symbols: File in wrong format
        ...

It’s grabbing the wrong libGL arch.

Checking


    cat /etc/ld.so.conf
        /usr/local/lib64
        /usr/lib64
        /usr/local/lib
        /usr/lib
        include /etc/ld.so.conf.d/*.conf
        # /lib64, /lib, /usr/lib64 and /usr/lib gets added
        # automatically by ldconfig after parsing this file.
        # So, they do not need to be listed.

the order should ne lib64 first.

If I move the 32-bit libGL libs out of the way


    mv /usr/lib/libGL.* /home/temp/

then


    ./bootstrap  ( <-- an autoreconf script that has '--copy --force' on the autofoo files)
    ./configure \
      --host=x86_64-suse-linux-gnu \
      --build=x86_64-suse-linux-gnu \
      ...
    make

completes as expected, correctly linking the 64-bit /usr/lib64/libGL.* libs.

Checking immediatlely after ./configure, I do find this


    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 /usr/lib64/xorg/modules'

Which, I think is causing of the actual make fail.

I’ve been having difficulty finding where the actual libpath problem originates in VLC source – libtool.m4, ltmain.sh, configure.ac, etc. Reading through their sources, they do NOT call out opensuse & its dual-arch libpath’s in any ‘case)’ clauses.

It’s also possible that the problem is in Opensuse’s “/usr/share/site/x86_64-unknown-linux-gnu”, or other autofoo config.

My 1st question here is: what’s the best approach do dealing with Opensuse-specific libpaths in general?

And, IDEALLY, anyone know of a specific workaround/fix for VLC sources?

2

On Wed 10 Jul 2013 01:06:01 AM CDT, darxsuse wrote:

I’m working on a native build of upstream VLC on an Opensuse 12.3/64
box; I’ll eventually package it up in obs for my own use.

My desktop has nvidia drivers installed “The hard way”. That install
results in libGL installed as dual-arch:

Code:

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 6 17:00 /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*

If I do a simple build of VLC on/for X86_64:

Code:

git clone git://git.videolan.org/vlc.git
./bootstrap
./configure
–host=x86_64-suse-linux-gnu
–build=x86_64-suse-linux-gnu
…
make

it fails at

Code:

…
make[4]: Entering directory
`/home/dev/vlc-master/modules/video_output’
CCLD libgl_plugin.la
/usr/lib/libGL.so: could not read symbols: File in wrong format
…

It’s grabbing the wrong libGL arch.

Checking

Code:

cat /etc/ld.so.conf
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
include /etc/ld.so.conf.d/*.conf

/lib64, /lib, /usr/lib64 and /usr/lib gets added

automatically by ldconfig after parsing this file.

So, they do not need to be listed.

the order should ne lib64 first.

If I move the 32-bit libGL libs out of the way

Code:

mv /usr/lib/libGL.* /home/temp/

then

Code:

./bootstrap ( ← an autoreconf script that has ‘–copy --force’ on
the autofoo files) ./configure
–host=x86_64-suse-linux-gnu
–build=x86_64-suse-linux-gnu
…
make

completes as expected, correctly linking the 64-bit /usr/lib64/libGL.*
libs.

Checking immediatlely after ./configure, I do find this

Code:

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 /usr/lib64/xorg/modules’

Which, I think is causing of the actual make fail.

I’ve been having difficulty finding where the actual libpath problem
originates in VLC source – libtool.m4, ltmain.sh, configure.ac, etc.
Reading through their sources, they do NOT call out opensuse & its
dual-arch libpath’s in any ‘case)’ clauses.

It’s also possible that the problem is in Opensuse’s
“/usr/share/site/x86_64-unknown-linux-gnu”, or other autofoo config.

My 1st question here is: what’s the best approach do dealing with
Opensuse-specific libpaths in general?

And, IDEALLY, anyone know of a specific workaround/fix for VLC sources?

Hi
After you run the bootstrap, just check your configure options
available, eg;


../configure --help

You probably also need to include;


../configure --libdir=/usr/lib64

When building on OBS using the %configure macro sorts all this out
including build and host entries…

The native VLC can’t be built on OBS, unless you remove all the patent
encumbered stuff… that’s why we have packman build service :wink:

Plus if you have a home repository on OBS, using osc for local builds
and a rpm spec file will make life a lot easier for you…

I guess understanding your end goal in building vlc, since the vlc
folks (who are also openSUSE packagers/maintainers) take care of things
pretty well…?

–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 12.3 (x86_64) Kernel 3.7.10-1.16-desktop
up 6:00, 3 users, load average: 0.15, 0.10, 0.08
CPU AMD Athlon™ II P360@2.30GHz | GPU Mobility Radeon HD 4200

3

hi malcolm,

./configure --libdir=/usr/lib64

Already done here, and has not effect on the outcome.

Iiuc, that option determines where my built libs will be installed – not where they’re being linked from, whether statically or dynamicall. Although, it does have some ‘toggle’ effect on the opensuse-specific autofoo stuff … I’m still digging around in there to figure it out. I think if it’s specified in a config, then the sys_llib_dlsearch_path should be all 64-bit. And therein lies the problem – it’s not. Rather, it’s mixed (or confused …)
> The native VLC can’t be built on OBS, unless you remove all the patentencumbered stuff… that’s why we have packman build service :wink:

Ah, the license biz; that may well be the case. Then I’ll continue to build my own just locally for now.

> using osc for local builds and a rpm spec file will make life a lot easier for you…

Which I’ll get to. AFTER I get the details of a native/upstream build ironed out. First we bake the cake, then we frost it …

> I guess understanding your end goal in building vlc

The big picture: The media stack packaged for opensuse doesn’t work for me in a variety of scenarios.

To solve my needs, I need VLC/2.2.x + ffmpeg-trunk + mplayer-trunk + XBMC-trunk. Those bleeding-edge versions are simply not packaged. Even if they are, they’re not configured for my needs, necessarily (paths, linked libs, blah blah). I’d also like my media stack functionality to be under my control, not some other packager’s.

The smaller/current picture: all that said, getting VLC-trunk to non-obs build to use the correct opensuse libpaths is still my 1st, desired step …

4

i’m beginning to suspect the problem starts in libtool.m4.

here’s an old thread that looks relevant,

sys_lib_dlsearch_path_spec set incorrectly on 64bit linux with /usr/lib6

and implies this is a BUG …

5

Moved to:

“Bug 829002 - 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

6

I have been encountering a the exact same issue “/usr/lib/libGL.so: could not read symbols: File in wrong format” and I believe the problem is with the file “libGL.so.319.23”. I have access to other machines that have older OpenGL libs (libGL.so.310.19) and on those machines the software builds to completion.

7

On Tue 03 Sep 2013 08:26:03 PM CDT, zdurban wrote:

darxsuse;2571029 Wrote:
> i’m beginning to suspect the problem starts in libtool.m4.
>
> here’s an old thread that looks relevant,
>
> ‘sys_lib_dlsearch_path_spec set incorrectly on 64bit linux with
> /usr/lib6’ (http://tinyurl.com/k34v3zy)
>
> and implies this is a BUG …

I have been encountering a the exact same issue “/usr/lib/libGL.so:
could not read symbols: File in wrong format” and I believe the problem
is with the file “libGL.so.319.23”. I have access to other machines that
have older OpenGL libs (libGL.so.310.19) and on those machines the
software builds to completion.

Hi
Does the same issue arise when building the version from OBS
multimedia:libs?

Speaking with on of the VLC folks, they indicate that the libtool.m4 indeed looks bogus…
However, the package likely does not expose the issues, as we build in
chroot, where the 32bit stuff is not there.

I suggest you use the OBS setup and osc to build locally which will
recreate the current build environment.

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 12.3 (x86_64) GNOME 3.8.4 Kernel 3.7.10-1.16-desktop
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

8

I solved the exact same error by changing the last line of the /usr/lib64/libGL.la file from:

libdir=‘/usr/lib’

to:

libdir=‘/usr/lib64’