Discussion:
[SDL] libSDL2_image: configure behaves differently on Debian vs Ubuntu?
Gianfranco Berardi
2017-03-03 04:34:43 UTC
Permalink
After almost a week of trying to figure this one out, I'm at a loss.
This is maybe more of an autotools or distro-specific question, but
perhaps someone here has more of a deeper understanding about what is
happening and can help.

I am trying to build my own custom SDL2* libraries. I can configure and
install SDL2 into an arbitrary directory just fine.

When I try to configure SDL2_image, pointing both the --prefix and
--with-sdl-prefix to that same arbitrary directory, it succeeds just
fine on Ubuntu.

But when I try to build on Debian Wheezy (mainly so my custom-built
libraries, which I plan to distribute with my project, will have fewer
dependencies than what Ubuntu pulls in), I am surprised to see the
following output:

$ ./configure --disable-bmp --disable-gif --disable-jpg
--disable-jpg-shared --disable-lbm --disable-pcx --enable-png
--enable-png-shared --disable-pnm --disable-tga --disable-tif
--disable-tif-shared --disable-xcf --disable-xpm --disable-xv
--disable-webp --disable-webp-shared
--prefix=/home/gb/Projects/Tools/CustomLibs/amd64
--with-sdl-prefix=/home/gb/Projects/Tools/CustomLibs/amd64

...

checking for SDL - version >= 2.0.0... no
*** Could not run SDL test program, checking why...
*** The test program compiled, but did not run. This usually means
*** that the run-time linker is not finding SDL or finding the wrong
*** version of SDL. If it is not finding SDL, you'll need to set your
*** LD_LIBRARY_PATH environment variable, or edit /etc/ld.so.conf to point
*** to the installed location Also, make sure you have run ldconfig if that
*** is required on your system
***
*** If you have an old version installed, it is best to remove it, although
*** you may also be able to get things to work by modifying LD_LIBRARY_PATH
configure: error: *** SDL version 2.0.0 not found!

Checking the Debian config.log, it looks like it is able to build
conftest using SDL2, so configure clearly knows how to find it using
sdl2-config, but when it tries to run conftest, the runtime linker
doesn't know where to look to find SDL2.

Debian's config.log:
configure:12352: checking for SDL - version >= 2.0.0
configure:12440: gcc -o conftest -g -O2
-I/home/gb/Projects/Tools/CustomLibs/amd64/include/SDL2 -D_REENTRANT
conftest.c -L/home/gb/Projects/Tools/CustomLibs/amd64/lib -lSDL2 >&5
configure:12440: $? = 0
configure:12440: ./conftest
./conftest: error while loading shared libraries: libSDL2-2.0.so.0:
cannot open shared object file: No such file or directory
configure:12440: $? = 127
configure: program exited with status 127

Debian: $ ls /home/gb/Projects/Tools/CustomLibs/amd64/lib/
cmake libSDL2-2.0.so.0 libSDL2-2.0.so.0.4.1 libSDL2.a libSDL2.la
libSDL2main.a libSDL2.so libSDL2_test.a pkgconfig


On Ubuntu 14.04, I see that config.log has a few key output variables,
such as LIBS, that point to the custom directory, whereas on Debian
Wheezy, those same output variables are missing that information.

Ubuntu's config.log:
configure:12352: checking for SDL - version >= 2.0.0
configure:12440: gcc -o conftest -g -O2
-I/home/gb/Projects/Tools/CustomLibs/amd64/include/SDL2 -D_REENTRANT
conftest.c -L/home/gb/Projects/Tools/CustomLibs/amd64/lib -lSDL2 >&5
configure:12440: $? = 0
configure:12440: ./conftest
configure:12440: $? = 0
configure:12455: result: yes

When I check the diffs between config.log files, I see how different
these seemingly important values are:

< CFLAGS='-I/usr/include/libpng12 -g -O2
-I/home/gb/Projects/Tools/CustomLibs/amd64/include/SDL2 -D_REENTRANT'
---
CFLAGS='-g -O2'
< SDL_CFLAGS='-I/home/gb/Projects/Tools/CustomLibs/amd64/include/SDL2
-D_REENTRANT'
< SDL_LIBS='-L/home/gb/Projects/Tools/CustomLibs/amd64/lib -lSDL2'
---
SDL_CFLAGS=''
SDL_LIBS=''
I could always using LD_LIBRARY_PATH or do what the README.txt says
about setting environment variables myself, but I am curious why running
configure on one system without doing those things results in behavior
that is different from the other system.

Any ideas?

Thanks for your time,
Gianfranco
--
Creating entertainment that encourages curiosity, supports creativity,
and promotes continuous learning: http://www.GBGames.com/

Follow me on Twitter: http://www.twitter.com/GBGames
Gianfranco Berardi
2017-03-13 11:42:35 UTC
Permalink
Post by Gianfranco Berardi
I could always using LD_LIBRARY_PATH or do what the README.txt says
about setting environment variables myself, but I am curious why running
configure on one system without doing those things results in behavior
that is different from the other system.
For posterity's sake, I thought I would respond with the latest
information I have. Please correct me if I am wrong.

When I built the test code that configure was trying, I found that the
issue is with the difference in linkers.

Debian Wheezy is using gcc 4.7, and 4.7's linker seems to add
dependencies because you told it that it that a library should be linked
in. That is, if you tell it to link in SDL2, it will have a dependency
on libSDL2. configure fails because it builds a test program that fails
to find the dependency because the run-time linker doesn't know where to
find it.

Ubuntu 14.04 uses gcc 4.8, which has a linker that is smarter about
checking if your resulting binary actually uses anything in the library
before deciding if it is a dependency. If you tell it to link in SDL2,
but none of the SDL2 library is actually used, it won't have a a
dependency. configure passes because the test program doesn't have a
dependency on something in a weird place and so avoids the need to have
its run-time linker pointed in the right direction.

So, in the end, I updated my build scripts so they use LD_LIBRARY_PATH
to point to the lib directory of my custom libraries when running
configure, and it works on both older and newer systems.

Hopefully this information helps someone.

-Gianfranco
--
Creating entertainment that encourages curiosity, supports creativity,
and promotes continuous learning: http://www.GBGames.com/

Follow me on Twitter: http://www.twitter.com/GBGames
Loading...