bugGNU Octave - Bugs: bug #44467, libGL error: failed to load...

 
 

bug #44467: libGL error: failed to load driver: swrast

Submitter:  ederag <ederag>
Submitted:  Sat 07 Mar 2015 12:37:16 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  3 - Low Item Group:  Incorrect Result
Status:  Invalid / Not an Octave Bug Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.0.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 26 Oct 2018 06:03:18 AM UTC, comment #23: 

Sorry, a correction: I have Ubuntu 18.04.1 LTS

The relevant part of my original post was:

I get: "libGL error: No matching fbConfigs or
visuals found
libGL error: failed to load driver: swrast"

when I launch this particular version of Octave. I have no such problem when I
launch Octave 4.2.2

I have an NVIDIA GPU. So why is this problem in the later version only?

Chip Reuben <chip_reuben>
Fri 26 Oct 2018 05:54:38 AM UTC, comment #22: 

In Ubuntu 16.4 in Octave 4.4.1 I get: "libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast"

when I launch this particular version of Octave. I have no such problem when I launch Octave 4.2.2

I have an NVIDIA GPU. So why is this problem in the later version only?

Chip Reuben <chip_reuben>
Tue 02 Jun 2015 04:37:09 PM UTC, comment #21: 

Retagging release from 4.0.0-rc1 to 4.0.0.

John W. Eaton <jwe>
Group administrator
Thu 12 Mar 2015 02:23:40 AM UTC, comment #20: 

Great, glad we were able to find the problem.

Mike Miller <mtmiller>
Group Member
Wed 11 Mar 2015 09:10:15 PM UTC, comment #19: 

Good catch, congratulations !

There are 17 libQt*.la in /usr/lib64

They should not be packaged, according to OpenSUSE recommendations
https://en.opensuse.org/Shared_Library_Packaging_Policy

>Avoid packaging libtool config files (.la files). If you do not package a static library, and if you are also placing the shared library in a standard search directory (i.e. %_lib, /usr/%_lib), they will not be needed.


And they all have multiple -L/usr/lib64 occurrences,
as you suspected.

Then

sudo mkdir /usr/lib64/old.la
sudo mv /usr/lib64/libQt*.la /usr/lib64/old.la/

./configure --with-blas="/usr/local/openblas-mt-gcc4.8.3/lib64/libopenblas.so" CFLAGS="-march=native -L/usr/local/openblas-mt-gcc4.8.3/lib64 -I/usr/local/openblas-mt-gcc4.8.3/include" CXXFLAGS="-march=native -L/usr/local/openblas-mt-gcc4.8.3/lib64 -I/usr/local/openblas-mt-gcc4.8.3/include" FFLAGS="-march=native -L/usr/local/openblas-mt-gcc4.8.3/lib64 -I/usr/local/openblas-mt-gcc4.8.3/include" LDFLAGS=-Wl,-rpath,/usr/local/openblas-mt-gcc4.8.3/lib64 --prefix=/usr/local/openblas-mt-gcc4.8.3

make clean
make -j 3

chrpath -l libgui/.libs/liboctgui.so
libgui/.libs/liboctgui.so: RUNPATH=/usr/local/build/octave-4.0.0-rc1/libinterp/.libs:/usr/local/build/octave-4.0.0-rc1/liboctave/.libs:/usr/local/openblas-mt-gcc4.8.3/lib64/octave/4.0.0-rc1:/usr/local/openblas-mt-gcc4.8.3/lib64

and the plot works fine now.

Bug report filed to OpenSUSE:
https://bugzilla.opensuse.org/show_bug.cgi?id=921875


Thanks a lot for your help !

ederag <ederag>
Tue 10 Mar 2015 11:11:13 PM UTC, comment #18: 

Based on the extra information you found, in particular this match:


... /usr/lib64/libQtNetwork.la -L/usr/lib64 /usr/lib64/libQtOpenGL.la ...


I suggest you look in your /usr/lib64 and /usr/X11R6/lib64 directories for Qt.la files and see if they contain the offending -L/usr/lib64 string.

The .la files are libtool library wrapper files. Most distributions do not install them because they can cause problems, and the ELF binary format for shared libraries on Linux has enough information that the .la file is not needed. If they are installed, then libtool will use the contents of the file to assemble into the linker command line.

So if openSUSE does indeed install the .la files in /usr/lib64, etc, and one of them has "-L/usr/lib64", then that is where the Octave build is picking it up from.

Mike Miller <mtmiller>
Group Member
Tue 10 Mar 2015 08:45:26 PM UTC, comment #17: 

Thanks for the links.
Indeed on opensuse 13.2 smbclient is incorrect:

>grep Libs /usr/lib64/pkgconfig/smbclient.pc

Libs: -Wl,-rpath,/usr/lib64 -L${libdir} -lsmbclient

> pkg-config --libs smbclient

-Wl,-rpath,/usr/lib64 -lsmbclient

Manually removing the rpath

>grep Libs /usr/lib64/pkgconfig/smbclient.pc

Libs: -L${libdir} -lsmbclient

> pkg-config --libs smbclient

-lsmbclient

does not resolve the problem.
./configure --with-blas="/usr/local/openblas-mt-gcc4.8.3/lib64/libopenblas.so" CFLAGS="-march=native -L/usr/local/openblas-mt-gcc4.8.3/lib64 -I/usr/local/openblas-mt-gcc4.8.3/include" CXXFLAGS="-march=native -L/usr/local/openblas-mt-gcc4.8.3/lib64 -I/usr/local/openblas-mt-gcc4.8.3/include" FFLAGS="-march=native -L/usr/local/openblas-mt-gcc4.8.3/lib64 -I/usr/local/openblas-mt-gcc4.8.3/include" LDFLAGS=-Wl,-rpath,/usr/local/openblas-mt-gcc4.8.3/lib64 --prefix=/usr/local/openblas-mt-gcc4.8.3 FLTK_LDFLAGS="-lfltk_gl -lGL -lfltk"
make clean
make -j 3 V=1 FLTK_LDFLAGS="-lfltk_gl -lGL -lfltk"

chrpath -l libgui/.libs/liboctgui.so
libgui/.libs/liboctgui.so: RUNPATH=/usr/local/build/octave-4.0.0-rc1/libinterp/.libs:/usr/local/build/octave-4.0.0-rc1/liboctave/.libs:/usr/lib64:/usr/local/openblas-mt-gcc4.8.3/lib64/octave/4.0.0-rc1:/usr/local/openblas-mt-gcc4.8.3/lib64

and actually, having increased the logging size of my konsole to 1e5 lines, I found the offending line

libtool: link: g++  -fPIC -DPIC -shared -nostdlib /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/crti.o /usr/lib64/gcc/x86_64-suse-linux/4.8/crtbeginS.o  -Wl,--whole-archive qterminal/.libs/libqterminal.a src/.libs/libgui-src.a graphics/.libs/libgui-graphics.a -Wl,--no-whole-archive  -Wl,-rpath -Wl,/usr/local/build/octave-4.0.0-rc1/libinterp/.libs -Wl,-rpath -Wl,/usr/local/build/octave-4.0.0-rc1/liboctave/.libs -Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath -Wl,/usr/local/openblas-mt-gcc4.8.3/lib64/octave/4.0.0-rc1 -Wl,-rpath -Wl,/usr/lib64 -L/usr/local/openblas-mt-gcc4.8.3/lib64 ../libinterp/.libs/liboctinterp.so ../liboctave/.libs/liboctave.so /usr/lib64/libQtNetwork.so /usr/lib64/libQtOpenGL.so /usr/lib64/libQtGui.so /usr/lib64/libQtCore.so -lqscintilla2 -lfontconfig -lfreetype -lGL -lGLU -lutil -L/usr/lib64/gcc/x86_64-suse-linux/4.8 -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../.. -lstdc++ -lm -lgomp -lpthread -lc -lgcc_s /usr/lib64/gcc/x86_64-suse-linux/4.8/crtendS.o /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/crtn.o  -pthread -fopenmp -march=native -Wl,-rpath -Wl,/usr/local/openblas-mt-gcc4.8.3/lib64   -pthread -fopenmp -Wl,-soname -Wl,liboctgui.so.0 -o .libs/liboctgui.so.0.0.0


Of course there can be another package with the same kind of flaw
(according to ldd, smbclient is not linked by octave)
I intend to follow this path further tomorrow.
And probably file a bug report to OpenSUSE also.

Another path would be to investigate the other files where /usr/lib64 was found in comment #16.

ederag <ederag>
Tue 10 Mar 2015 08:17:46 PM UTC, comment #16: 

Here is an answer to your question about other instances of /usr/lib64 in Makefiles. And a search in other files too.
I'll follow up on the next part of your comment in another post.


Searching through the previous 1e4 lines of output, I haven't been able to find any offending /usr/lib64.

find . -name Makefile -exec grep "\/usr\/lib64[^\/]" {} \;
yields only lines like
FLTK_LDFLAGS = -L/usr/lib64 -lfltk_gl -lGL -lfltk

I also searched the full output of
find . -name Makefile -exec grep "\/usr\/lib64" {} \; -print
for good measure. Nothing else there.

looking in all non-binary file lines containing /usr/lib64
but not FLTK_LDFLAGS:
find . -type f -exec grep -I "\/usr\/lib64[^\/]" {} \; -print | grep -v FLTK_LDFLAGS
yields some new occurences:

dependency_libs=' /usr/local/openblas-mt-gcc4.8.3/lib64/octave/4.0.0-rc1/liboctinterp.la -lhdf5 -lz -lX11 -lgl2ps /usr/local/openblas-mt-gcc4.8.3/lib64/octave/4.0.0-rc1/liboctave.la -lcurl -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse /usr/local/openblas-mt-gcc4.8.3/lib64/libarpack.la -lqrupdate /usr/local/openblas-mt-gcc4.8.3/lib64/libfftw3_threads.la /usr/local/openblas-mt-gcc4.8.3/lib64/libfftw3.la /usr/local/openblas-mt-gcc4.8.3/lib64/libfftw3f_threads.la /usr/local/openblas-mt-gcc4.8.3/lib64/libfftw3f.la -lreadline -lncurses -lpcre -ldl -lgfortran -lquadmath /usr/lib64/libQtNetwork.la -L/usr/lib64 /usr/lib64/libQtOpenGL.la -L/usr/X11R6/lib -lQtGui /usr/lib64/libQtGui.la -lQtCore /usr/lib64/libQtCore.la -lqscintilla2 -lfontconfig -lfreetype -lGL -lGLU -lutil'
in
./libgui/.libs/liboctgui.lai

./libgui/.libs/liboctgui.lai
dependency_libs=' /usr/local/build/octave-4.0.0-rc1/libinterp/liboctinterp.la -lhdf5 -lz -lX11 -lgl2ps /usr/local/build/octave-4.0.0-rc1/liboctave/liboctave.la -lcurl -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse /usr/local/openblas-mt-gcc4.8.3/lib64/libarpack.la -lqrupdate /usr/local/openblas-mt-gcc4.8.3/lib64/libfftw3_threads.la /usr/local/openblas-mt-gcc4.8.3/lib64/libfftw3.la /usr/local/openblas-mt-gcc4.8.3/lib64/libfftw3f_threads.la /usr/local/openblas-mt-gcc4.8.3/lib64/libfftw3f.la -lreadline -lncurses -lpcre -ldl -lgfortran -lquadmath /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/libQtNetwork.la -L/usr/lib64 /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/libQtOpenGL.la -L/usr/X11R6/lib -lQtGui /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/libQtGui.la -lQtCore /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/libQtCore.la -lqscintilla2 -lfontconfig -lfreetype -lGL -lGLU -lutil'
in
./libgui/liboctgui.la

        /usr/lib | /usr/lib64 | /lib | /lib64) ;;
in
./configure

Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-4.8 --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
in
./config.log

sys_lib_search_path_spec='/usr/lib64/gcc/x86_64-suse-linux/4.8 /usr/lib64 /lib64 /usr/x86_64-suse-linux/lib '
in
./config.status

sys_lib_search_path_spec="/usr/lib64/gcc/x86_64-suse-linux/4.8 /usr/lib64 /lib64 /usr/x86_64-suse-linux/lib "
in
./libtool

ederag <ederag>
Tue 10 Mar 2015 01:10:18 AM UTC, comment #15: 

Is there any chance you can find other instances of "/usr/lib64" in the Makefile(s) after running configure, maybe in a different variable from FLTK_LDFLAGS?

I did some quick searching and found other people with similar problems, for example this chain of threads:


And the resolution turned out to be an error in the openSUSE packaging of samba, incorrectly including an rpath option pointing to /usr/lib64.

Mike Miller <mtmiller>
Group Member
Mon 09 Mar 2015 09:51:01 PM UTC, comment #14: 

Thanks for the V=1, very handy.


make clean
make -j 3 V=1 FLTK_LDFLAGS="-lfltk_gl -lGL -lfltk"

does not work either:
chrpath -l libgui/.libs/liboctgui.so
libgui/.libs/liboctgui.so: RUNPATH=/usr/local/build/octave-4.0.0-rc1/libinterp/.libs:/usr/local/build/octave-4.0.0-rc1/liboctave/.libs:/usr/lib64:/usr/local/openblas-mt-gcc4.8.3/lib64/octave/4.0.0-rc1:/usr/local/openblas-mt-gcc4.8.3/lib64


although it seems to really override the FLTK_LDFLAGS,
since there are lines like

/bin/sh ../libtool  --tag=CXX   --mode=link g++ -pthread -fopenmp -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -march=native -L/usr/local/openblas-mt-gcc4.8.3/lib64 -I/usr/local/openblas-mt-gcc4.8.3/include -avoid-version -module -no-undefined -lfltk_gl -lGL -lfltk  -Wl,-rpath,/usr/local/openblas-mt-gcc4.8.3/lib64  -Wl,-rpath,/usr/local/openblas-mt-gcc4.8.3/lib64 -o dldfcn/__fltk_uigetfile__.la -rpath /usr/local/openblas-mt-gcc4.8.3/lib64/octave/4.0.0-rc1 dldfcn/dldfcn___fltk_uigetfile___la-__fltk_uigetfile__.lo liboctinterp.la ../liboctave/liboctave.la  -lfreetype   -lutil -lm

I'll look into all the lines tomorrow.

ederag <ederag>
Mon 09 Mar 2015 09:23:37 PM UTC, comment #13: 

You can pass V=1 to make to get it to print verbosely.  This will at least let you see early what the compilation flags look like. 


make -j 3 V=1 FLTK_LDFLAGS="-lfltk_gl -lGL -lfltk"


I think you need to do a 'make clean' before that so that the re-compilation with the new FLTK_LDFLAGS variable will get set.

Rik <rik5>
Group administrator
Sun 08 Mar 2015 09:13:44 PM UTC, comment #12: 

make -j 3 FLTK_LDFLAGS="-lfltk_gl -lGL -lfltk"
does not change anything, neither do
FLTK_LDFLAGS="-lfltk_gl -lGL -lfltk" make -j 3
but weirdly
make -j 3
does not relink (it finishes really fast)
so I'm not sure the FLTK_LDFLAGS are overridden.
or maybe the evil is already done.
Unfortunately the real commands are abbreviated as CC, CXX, CXXLD...


Even added in the configure step, it does not fix the issue.
./configure --with-blas="/usr/local/openblas-mt-gcc4.8.3/lib64/libopenblas.so" CFLAGS="-march=native -L/usr/local/openblas-mt-gcc4.8.3/lib64 -I/usr/local/openblas-mt-gcc4.8.3/include" CXXFLAGS="-march=native -L/usr/local/openblas-mt-gcc4.8.3/lib64 -I/usr/local/openblas-mt-gcc4.8.3/include" FFLAGS="-march=native -L/usr/local/openblas-mt-gcc4.8.3/lib64 -I/usr/local/openblas-mt-gcc4.8.3/include" LDFLAGS=-Wl,-rpath,/usr/local/openblas-mt-gcc4.8.3/lib64 --prefix=/usr/local/openblas-mt-gcc4.8.3 FLTK_LDFLAGS="-lfltk_gl -lGL -lfltk"
make

chrpath -l libgui/.libs/liboctgui.so
libgui/.libs/liboctgui.so: RUNPATH=/usr/local/build/octave-4.0.0-rc1/libinterp/.libs:/usr/local/build/octave-4.0.0-rc1/liboctave/.libs:/usr/lib64:/usr/local/openblas-mt-gcc4.8.3/lib64/octave/4.0.0-rc1:/usr/local/openblas-mt-gcc4.8.3/lib64


But then it can be seen that FLTK_LDFLAGS are not overridden:
find . -name Makefile -exec grep FLTK_LDFLAGS {} \;
There are plenty of

FLTK_LDFLAGS = -L/usr/lib64 -lfltk_gl -lGL -lfltk

config_opts =  '--with-blas=/usr/local/openblas-mt-gcc4.8.3/lib64/libopenblas.so' 'CFLAGS=-march=native -L/usr/local/openblas-mt-gcc4.8.3/lib64 -I/usr/local/openblas-mt-gcc4.8.3/include' 'CXXFLAGS=-march=native -L/usr/local/openblas-mt-gcc4.8.3/lib64 -I/usr/local/openblas-mt-gcc4.8.3/include' 'FFLAGS=-march=native -L/usr/local/openblas-mt-gcc4.8.3/lib64 -I/usr/local/openblas-mt-gcc4.8.3/include' 'LDFLAGS=-Wl,-rpath,/usr/local/openblas-mt-gcc4.8.3/lib64' '--prefix=/usr/local/openblas-mt-gcc4.8.3' 'FLTK_LDFLAGS=-lfltk_gl -lGL -lfltk' 'JAVA_HOME=/usr/lib64/jvm/jre'

Thanks again.

ederag <ederag>
Sun 08 Mar 2015 06:50:48 PM UTC, comment #11: 

It certainly could be the FLTK_LDFLAGS. Can you override that variable when you build Octave to remove the -L option and see if that changes anything? Running `make FLTK_LDFLAGS="..."` should override the value set by configure. By the way, that string comes from running `fltk-config --use-gl --ldflags` as provided by your distro. On my system the output does not include a -L option.

I think libtool is the one responsible for deciding what linker flags are needed when building the libraries and executables, for example figuring out which -L options need to be turned into rpath options. I think it is normally supposed to ignore -L options that refer to the system default library directories. I may not be entirely right about that, but that may be another place to look.

Mike Miller <mtmiller>
Group Member
Sun 08 Mar 2015 05:18:02 PM UTC, comment #10: 

Thanks a lot for your help.
The comparison with other systems is useful.
You are right that having both GL libs is not good.
But why is the /usr/lib64 added to the runpath is puzzling me
since on any decent system it would be in the ld.so.conf anyway.
I've got to think about it.

Just to be sure it was not buried too deep into my comment #7:
the FLTK_LDFLAGS can not be the culprit ?


Meanwhile, here is a workaround:

chrpath -r $(chrpath -l ./libgui/.libs/liboctgui.so | cut -d '=' -f '2' | awk '{gsub(/\/usr\/lib64/, "")}; 1') ./libgui/.libs/liboctgui.so

which simply replaces the runpath ./libgui/.libs/liboctgui.so with a new one without the offending /usr/lib64

ederag <ederag>
Sun 08 Mar 2015 03:28:05 PM UTC, comment #9: 

I can't account for the differences you are seeing. It sounds like you are on the right path though to figuring out what is different. You should keep looking along these lines to find out what the linking difference is and what it should be on your openSUSE system with nvidia drivers installed.

I'll keep this bug report open for now, just in case there is something Octave could do to improve the linking situation when you are able to find out what needs to be done, but it really is coming down to some local library path configuration issue. For comparison, on Debian and on CentOS, when the nvidia GL libraries are installed, the original mesa GL libraries are diverted to a different directory so they are no longer reachable. Having both the original mesa library and the nvidia library linkable at the same time seems to me like a situation ripe for problems.

Mike Miller <mtmiller>
Group Member
Sun 08 Mar 2015 10:54:30 AM UTC, comment #8: 

Another hint:

For octave-3.8.2 built in the same way, the /usr/lib64 was already in the rpath :
chrpath -l ./libgui/.libs/liboctgui.so
./libgui/.libs/liboctgui.so: RUNPATH=/usr/local/build/octave-3.8.2/libinterp/.libs:/usr/local/build/octave-3.8.2/liboctave/.libs:/usr/lib64:/usr/local/openblas-mt-gcc4.8.3/lib64/octave/3.8.2:/usr/local/openblas-mt-gcc4.8.3/lib64

But it did not trigger the errors
graphics_toolkit
fltk

And indeed, while the /usr/lib64 is in the runpath, the right libGL.so is used :
ldd  ./libgui/.libs/liboctgui.so | grep libGL                                                  
        libGL.so.1 => /usr/X11R6/lib64/libGL.so.1 (0x00007f2669d32000)
        libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00007f2669ab3000)

ederag <ederag>
Sun 08 Mar 2015 10:40:26 AM UTC, comment #7: 

Thanks for your help.

ldd src/.libs/lt-octave-gui | grep libGL
ldd: src/.libs/lt-octave-gui: No such file or directory

Actually
find . -name "lt-*"
yields nothing. Maybe because I did not make install yet ?

chrpath -l ./libinterp/.libs/liboctinterp.so
./libinterp/.libs/liboctinterp.so: RUNPATH=/usr/local/build/octave-4.0.0-rc1/liboctave/.libs:/usr/local/openblas-mt-gcc4.8.3/lib64:/usr/local/openblas-mt-gcc4.8.3/lib64/octave/4.0.0-rc1

chrpath -l ./liboctave/.libs/liboctave.so
./liboctave/.libs/liboctave.so: RUNPATH=/usr/local/openblas-mt-gcc4.8.3/lib64

But here is the offending /usr/lib64:
chrpath -l ./libgui/.libs/liboctgui.so
./libgui/.libs/liboctgui.so: RUNPATH=/usr/local/build/octave-4.0.0-rc1/libinterp/.libs:/usr/local/build/octave-4.0.0-rc1/liboctave/.libs:/usr/lib64:/usr/local/openblas-mt-gcc4.8.3/lib64/octave/4.0.0-rc1:/usr/local/openblas-mt-gcc4.8.3/lib64


And indeed in ./libtool there are

sys_lib_search_path_spec="/usr/lib64/gcc/x86_64-suse-linux/4.8 /usr/lib64 /lib64 /usr/x86_64-suse-linux/lib "

# The library search path used internally by the compiler when linking
# a shared library.
compiler_lib_search_path="-L/usr/local/openblas-mt-gcc4.8.3/lib64 -L/usr/lib64/gcc/x86_64-suse-linux/4.8 -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../.."

compiler_lib_search_path="-L/usr/local/openblas-mt-gcc4.8.3/lib64 -L/usr/lib64/gcc/x86_64-suse-linux/4.8 -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../.."


but why would these add an rpath for some libs and not others ?

searching for lib64, there are plenty of
FLTK_LDFLAGS = -L/usr/lib64 -lfltk_gl -lGL -lfltk
could it be related ?


Trying workarounds
add -L/usr/X11R6/lib64 to the LDFLAGS like
./configure [...] LDFLAGS="-L/usr/X11R6/lib64 -Wl,-rpath,/usr/local/openblas-mt-gcc4.8.3/lib64" [...]
make -j 3
to no avail.

or as rpath, also in the LDFLAGS
./configure [...] LDFLAGS=-Wl,-rpath,/usr/local/openblas-mt-gcc4.8.3/lib64:/usr/X11R6/lib64 [...]

which doe not work either, because unfortunately these are appended, not prepended :

chrpath -l ./libgui/.libs/liboctgui.so
./libgui/.libs/liboctgui.so: RUNPATH=/usr/local/build/octave-4.0.0-rc1/libinterp/.libs:/usr/local/build/octave-4.0.0-rc1/liboctave/.libs:/usr/lib64:/usr/local/openblas-mt-gcc4.8.3/lib64/octave/4.0.0-rc1:/usr/local/openblas-mt-gcc4.8.3/lib64:/usr/X11R6/lib64


Reading your comment again, here is the readelf output now:

readelf -d ./libgui/.libs/liboctgui.so

Dynamic section at offset 0x338f40 contains 44 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [liboctinterp.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [liboctave.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libQtNetwork.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [libQtOpenGL.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [libQtGui.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [libQtCore.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [libqscintilla2.so.11]
 0x0000000000000001 (NEEDED)             Shared library: [libfontconfig.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libfreetype.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libGL.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libGLU.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libutil.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgomp.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x000000000000000e (SONAME)             Library soname: [liboctgui.so.0]
 0x000000000000001d (RUNPATH)            Library runpath: [/usr/local/build/octave-4.0.0-rc1/libinterp/.libs:/usr/local/build/octave-4.0.0-rc1/liboctave/.libs:/usr/lib64:/usr/local/openblas-mt-gcc4.8.3/lib64/octave/4.0.0-rc1:/usr/local/openblas-mt-gcc4.8.3/lib64:/usr/X11R6/lib64]

and of ldd
ldd ./libgui/.libs/liboctgui.so | grep libGL
        libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f4e1d394000)
        libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00007f4e1d114000)

ederag <ederag>
Sun 08 Mar 2015 12:18:02 AM UTC, comment #6: 

Thanks for the responses. This still seems like a local library path configuration issue. Note that QtCreator has nothing to do with Octave. The linked questions look to me to be about running a project from within QtCreator, which is not the case here.

Can you show what `ldd src/.libs/lt-octave-gui | grep libGL` lists? You might also look at `chrpath -l` or `readelf -d` on src/.libs/lt-octave* and on libinterp/.libs/liboctinterp.so.

The src/octave program is actually just a simple wrapper for octave-cli and octave-gui. Can you try your chrpath commands on the src/.libs/lt-octave-cli and src/.libs/lt-octave-gui executables instead and see if it changes anything?

I would not be surprised if libtool might be inserting an rpath attribute pointing to /usr/lib64 since that is where most of your system libraries are. If we find that there is a /usr/lib64 rpath somewhere, you should be able to work around that with an extra argument in LDFLAGS for the /usr/X11R6/lib64 directory, right?

Mike Miller <mtmiller>
Group Member
Sat 07 Mar 2015 11:24:04 PM UTC, comment #5: 

I forgot to state that
find /usr/local/openblas-mt-gcc4.8.3/lib64 -name "libGL*"
yields nothing.

ederag <ederag>
Sat 07 Mar 2015 10:55:23 PM UTC, comment #4: 

I'll try to answer in order.

Here is the configure step

./configure --with-blas="/usr/local/openblas-mt-gcc4.8.3/lib64/libopenblas.so" CFLAGS="-march=native -L/usr/local/openblas-mt-gcc4.8.3/lib64 -I/usr/local/openblas-mt-gcc4.8.3/include" CXXFLAGS="-march=native -L/usr/local/openblas-mt-gcc4.8.3/lib64 -I/usr/local/openblas-mt-gcc4.8.3/include" FFLAGS="-march=native -L/usr/local/openblas-mt-gcc4.8.3/lib64 -I/usr/local/openblas-mt-gcc4.8.3/include" LDFLAGS=-Wl,-rpath,/usr/local/openblas-mt-gcc4.8.3/lib64 --prefix=/usr/local/openblas-mt-gcc4.8.3

make -j 3
make check

I also tried a simple ./configure, but got
configure: error: A BLAS library was detected but found incompatible with your Fortran 77 compiler settings.


This version is not installed yet, I test it with ./run-octave


echo $LD_LIBRARY_PATH
yields an empty line


From http://stackoverflow.com/q/27659516/3565696
it seems that Qt is the culprit

[...]
QProcess::start use by qtcreator add /usr/lib64 to
LD_LIBRARY_PATH in the environment which break the correct
localisation indicated by the linker (with command ldd)
(libGL.so.1 => /usr/lib64/nvidia/libGL.so.1

[...] all tentatives to change LD_LIBRARY_PATH from qtcreator failed, Qprocess::start append /usr/lib64 in front of it?



chrpath -l src/octave
src/octave: RUNPATH=/usr/local/openblas-mt-gcc4.8.3/lib64


with
LD_LIBRARY_PATH=/usr/X11R6/lib64:$LD_LIBRARY_PATH ./run-octave
it works fine (plot(1:10) without messages)
And fine also with
LIBGL_DEBUG=verbose LD_LIBRARY_PATH=/usr/X11R6/lib64:$LD_LIBRARY_PATH ./run-octave

Interesting, this seems against the "prepend /usr/lib64 in front of LD_LIBRARY_PATH" interpretation.


Another hint (?): after
chrpath -r /usr/X11R6/lib64 src/octave
src/octave: RUNPATH=/usr/local/openblas-mt-gcc4.8.3/lib64
src/octave: new RUNPATH: /usr/X11R6/lib64
./run-octave
plot(1:10)
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

ederag <ederag>
Sat 07 Mar 2015 09:11:36 PM UTC, comment #3: 

How did you compile and install Octave? Does your environment have an LD_LIBRARY_PATH normally? What is changing the library load path when Octave is run? Do the Octave executable or libraries have an rpath attribute adding /usr/lib64 to the library search path? If you set LD_LIBRARY_PATH to look in /usr/X11R6/lib64 first does Octave work?

Mike Miller <mtmiller>
Group Member
Sat 07 Mar 2015 05:56:14 PM UTC, comment #2: 

Thanks for your reply.
Both glxinfo, glxgears work as expected
LIBGL_DEBUG=verbose glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
302 frames in 5.0 seconds = 60.263 FPS

while after running octave (with or without --no-gui)
LIBGL_DEBUG=verbose ./run-octave
plot(1:10)
libGL: screen 0 does not appear to be DRI3 capable
libGL: screen 0 does not appear to be DRI2 capable
libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so
libGL: Can't open configuration file /home/<user>/.drirc: No such file or directory.
libGL: Can't open configuration file /home/<user>/.drirc: No such file or directory.
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

Forcing the wrong library path before running glxgears yield the same error:
LD_LIBRARY_PATH=/usr/lib64/:$LD_LIBRARY_PATH glxgears
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
363 frames in 5.3 seconds = 68.253 FPS
Side note: while the refresh rate is about the same, in this case, the animation is jerky.

ederag <ederag>
Sat 07 Mar 2015 04:09:44 PM UTC, comment #1: 

Thanks for your bug report. Do any OpenGL applications work on your system (glxinfo, glxgears, etc)? Does setting LIBGL_DEBUG=verbose in your environment provide any more information?

Mike Miller <mtmiller>
Group Member
Sat 07 Mar 2015 12:37:16 PM UTC, original submission:  

on openSUSE 13.2, Qt version 4.8.6, in the gui, when trying

plot(1:10)
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

The same errors happen once during make check, in
libinterp/corefcn/graphics.cc-tst

According to this question on stackoverflow, and this bug report, the problem is that
LD_LIBRARY_PATH is overridden somewhere.

Like in this reports, I'm using the proprietray nvidia drivers.
They add /etc/ld.so.conf.d/nvidia-gfxG03.conf which contains
/usr/X11R6/lib64
/usr/X11R6/lib
and indeed
/usr/X11R6/lib64/libGL.so -> libGL.so.1
/usr/X11R6/lib64/libGL.so.1 -> libGL.so.340.76
/usr/X11R6/lib64/libGL.so.340.76
should be used.

But there are also
/usr/lib64/libGL.so -> libGL.so.1.2.0
/usr/lib64/libGL.so.1 -> libGL.so.1.2.0
/usr/lib64/libGL.so.1.2 -> libGL.so.1.2.0
/usr/lib64/libGL.so.1.2.0

ederag <ederag>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by chip_reuben (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by ederag (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-10-26 mtmiller Carbon-CopyRemoved 80942 -
    2015-06-02 jwe Release4.0.0-rc1 4.0.0
    2015-03-12 mtmiller StatusNeed Info Invalid / Not an Octave Bug
        Open/ClosedOpen Closed
    2015-03-08 mtmiller Priority5 - Normal 3 - Low
    2015-03-07 mtmiller Item GroupNone Incorrect Result
        StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code