compiling shared library with already-built library (


This is a bit of a long shot. This is related to

I discovered that the /usr/lib64/ in LEAP 15.2 and TW are compiled without links to libGLX or libGLdispatch. Right now, the work around is to use the libvglfaker from LEAP 15.1 but I want to recompile the provided by VirtualGL in LEAP 15.2 repository.


ldd /usr/lib64/ (0x00007fff9eaf5000) => /lib64/ (0x00007ff3da73c000) => /usr/lib64/ (0x00007ff3da4ab000) => /usr/lib64/ (0x00007ff3da23a000) => /usr/lib64/ (0x00007ff3da034000) => /usr/lib64/ (0x00007ff3d9cf3000) => /usr/lib64/ (0x00007ff3d9ae1000) => /lib64/ (0x00007ff3d98c2000) => /lib64/ (0x00007ff3d958a000) => /lib64/ (0x00007ff3d91cf000)
        /lib64/ (0x00007ff3dabf4000) => /usr/lib64/ (0x00007ff3d8f9d000) => /usr/lib64/ (0x00007ff3d8ce7000) => /usr/lib64/ (0x00007ff3d8abe000) => /usr/lib64/ (0x00007ff3d88ba000)

not working 15.2/TW

ldd /usr/lib64/ (0x00007f58ab51c000) => /lib64/ (0x00007f58ab3fd000) => /usr/lib64/ (0x00007f58ab35e000) => /usr/lib64/ (0x00007f58ab356000) => /usr/lib64/ (0x00007f58ab211000) => /usr/lib64/ (0x00007f58ab1fc000) => /lib64/ (0x00007f58ab1da000) => /lib64/ (0x00007f58ab092000) => /lib64/ (0x00007f58aaec7000)
 /lib64/ (0x00007f58ab51e000) => /usr/lib64/ (0x00007f58aae9c000) => /usr/lib64/ (0x00007f58aae97000)

I don’t want to go as far as to re-compiling VirtualGL from source (another issue with Turbo-Jpeg) and I’ve already confirmed this bug

I am trying to compile just this library as a “cheap” solution. I tried compiling with (so.back is the original TW library)

gcc -shared -Wl, /usr/lib64/ /lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /lib64/ /lib64/ /lib64/ /lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/  -o ./

links are correct (0x00007ffe9d1d6000) (0x00007fbfa4f09000) => /lib64/ (0x00007fbfa4ed2000) => /usr/lib64/ (0x00007fbfa4e46000) => /usr/lib64/ (0x00007fbfa4da7000) => /usr/lib64/ (0x00007fbfa4d9f000) => /usr/lib64/ (0x00007fbfa4c5a000) => /usr/lib64/ (0x00007fbfa4c43000) => /lib64/ (0x00007fbfa4c21000) => /lib64/ (0x00007fbfa4adb000) => /lib64/ (0x00007fbfa4910000)
        /lib64/ (0x00007fbfa4f15000) => /usr/lib64/ (0x00007fbfa48de000) => /usr/lib64/ (0x00007fbfa4826000) => /usr/lib64/ (0x00007fbfa47f9000) => /usr/lib64/ (0x00007fbfa47f4000)

but obviously compiled is not the right size or length and and it does not work and is missing the simplest package. undefined symbol: _vgl_dlopen

Is there a way to re-compile a pre-compiled shared libraries provided by Zypper with more linkers?

Maybe update to 2.6.5 will solve this problem?

Fixed an oversight whereby the addresses of the interposed glDrawBuffers(), glGetString(), and glGetStringi() functions introduced in 2.6.3[2] and 2.6.4[1] were not returned from the interposed glXGetProcAddress() and glXGetProcAddressARB() functions.

I am not opposed to the upgrade, and I am sure it will fix the issue, and I hope based on the bug report the developers will push it in the next update. There’s a separate issue when I try to compile VirtualGL directly from their source git, OpenSUSE is missing the include shared header for turbojpeg. I guess rpm from the sourceforge should be good enough.

In any case, is there any way to recompile a comiled shared library without the source code? I know that for smaller codes, we can link pretty much any packages with anything without the source code.

Furthermore, where would be the source code be for this specific source code be as long as zypper is concerned?

Is there any reason why this VirtualGL shouldn’t be used instead of the official Leap 15.2/TW version? It seems to be mained more frequently.

It will, thought you might want to try it out before it’s released…

Cannot find it in .

Community repo from some person.

Branches on OBS are for maintenance, not normally available in search since by default it doesn’t publish. Need an OBS account to download though (or use osc getbinaries).

Yes, I just checked out his page ( and it’s registered on the software website. Also his packages are not digitally signed and YAST refuses to allow his repository to be added

Honestly, I hope his build merges with main release VGL because I cannot really recommend something like this in a set of instructions or recommend to someone but the build VGL is also broken.

Some person? A contributor…

rpm -qa --changelog | grep "dmueller" | wc -l

It is possible to get code in assembly language. Then it is possible to convert it to (bad) C/C++.
Make your changes, compile, use.
But for what? You have source code with a free license, responding developers, bug trackers, etc. …

Good points, but as I said, this is for a “cheap” solution. Doing the least amount of work to get most. Obviously if this doesn’t lead to quick clean solution, I’ll pursue another option. In this case is really requesting the factory VirtualGL to be updated as soon as possible, this is an issue for LEAP 15.2 and TW.

Test for VirtualGL 2.6.5 + bug report?

Will do but it will take some time… Holiday season.

Just checked the experimental X11:bumblebee repos. Still no good. from experimental bumbleee:

Dec 24 10:18 /usr/lib64/
ldd /usr/lib64/      (0x00007fff7e75d000) => /lib64/ (0x00007f089eee9000) => /usr/lib64/ (0x00007f089ee4a000) => /usr/lib64/ (0x00007f089ee42000) => /usr/lib64/ (0x00007f089ecfd000) => /usr/lib64/ (0x00007f089ece8000) => /lib64/ (0x00007f089ecc6000) => /lib64/ (0x00007f089eb7e000) => /lib64/ (0x00007f089e9b3000)
        /lib64/ (0x00007f089f00c000) => /usr/lib64/ (0x00007f089e988000) => /usr/lib64/ (0x00007f089e983000)

Still missing the proper linkers for CUDA to work.

Will put in bug report.

Instead of a new bugreport, I updated the existing bugreport shared before.

I’ve also assigned the bug to Dirk Mueller in Bugzilla, I hope he doesn’t mind. It’ll literally be just 2 extra linkers to add in the compiler.