wxGTK: configure and --with-libpng=builtin question

[Fulvio Senore]

I have configured and built a recent svn trunk with this configure line:

../configure --with-gtk --disable-shared --enable-unicode
--with-expat=builtin --with-zlib=builtin --with-libjpeg=builtin
--with-libtiff=builtin -with-libpng=builtin

Now I have a problem with the png library: I have discovered that if I
build the image sample and I run "ldd image" I get (among others) the
following output line:

libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb744d000)

so it looks like the program is still using the system libpng. BTW, the
same happens for expat.

In the ldd output I do not see any reference to the jpeg or tiff
library, for example, so it looks like those libraries are statically
linked as requested.

My Linux knowledge is limited so I don't know if I am missing something,
or is there some problem with --with-libtiff=builtin (and expat) handling?

Thanks in advance

Fulvio Senore

P.S. here is the full ldd output (ubuntu 8.04):

fulvio@fulvio-ubuntu-804-32bit:~/wxSVN/buildgtk/samples/image$ ldd image
linux-gate.so.1 => (0xb7ee6000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7b5e000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb7ada000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb7abf000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb7aa7000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb7a9e000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7a61000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb79ff000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb79c3000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb79be000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb79ba000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb79b5000)
librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb79ac000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb78fb000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7814000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xb780b000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb77e6000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb76f3000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb76e8000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb76d0000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7581000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb757d000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb757a000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7575000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb754b000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb753d000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7534000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb7531000)
libXi.so.6 => /usr/lib/libXi.so.6 (0xb7529000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb7523000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb751a000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb74f2000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7485000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7470000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb744d000)
libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb7424000)
/lib/ld-linux.so.2 (0xb7ee7000)
libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb73fc000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb73fa000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb73e2000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xb73ca000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb73a9000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb73a5000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb73a0000)

[Fulvio Senore]

I can't believe it, but I have just seen the typo in the configure line.
I will build the library again with a correct configure line and I will
report if the problem still happens. I believe that it should happen
because I noticed it also in another installation, but I will report as
soon as possible.

My apologies.

Fulvio Senore

[Fulvio Senore]

My previous post contained a typo in the configure line. I have rebuilt
the library and I still have the same problem, so I am reporting here
the original post again (with updated output) to help readers.

I have configured and built a recent svn trunk with this configure line:

../configure --with-gtk --disable-shared --enable-unicode
--with-expat=builtin --with-zlib=builtin --with-libjpeg=builtin

--with-libtiff=builtin --with-libpng=builtin

Now I have a problem with the png library: I have discovered that if I
build the image sample and I run "ldd image" I get (among others) the
following output line:

libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb74fb000)

so it looks like the program is still using the system libpng. BTW, the
same happens for expat.

In the ldd output I do not see any reference to the jpeg or tiff
library, for example, so it looks like those libraries are statically
linked as requested.

My Linux knowledge is limited so I don't know if I am missing something,
or is there some problem with --with-libtiff=builtin (and expat) handling?

Thanks in advance

Fulvio Senore

P.S. here is the full ldd output (ubuntu 8.04):

fulvio@fulvio-ubuntu-804-32bit:~/wxSVN/buildgtk/samples/image$ ldd image

linux-gate.so.1 => (0xb7f94000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7c0c000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb7b88000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb7b6d000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb7b55000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb7b4c000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7b0f000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb7aad000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7a71000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7a6c000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7a68000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7a63000)
librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7a5a000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb79a9000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb78c2000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xb78b9000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7894000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb77a1000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7796000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb777e000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb762f000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb762b000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb7628000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7623000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb75f9000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb75eb000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb75e2000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb75df000)
libXi.so.6 => /usr/lib/libXi.so.6 (0xb75d7000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb75d1000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb75c8000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb75a0000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7533000)
libz.so.1 => /usr/lib/libz.so.1 (0xb751e000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb74fb000)
libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb74d2000)
/lib/ld-linux.so.2 (0xb7f95000)
libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb74aa000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb74a8000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb7490000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xb7478000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7457000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7453000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb744e000)

[Vadim Zeitlin]

On Mon, 11 Jun 2012 10:37:44 +0200 Fulvio Senore wrote:

FS> Now I have a problem with the png library: I have discovered that if I
FS> build the image sample and I run "ldd image" I get (among others) the
FS> following output line:
FS>
FS> libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb74fb000)
FS>
FS> so it looks like the program is still using the system libpng.

This is due to an indirect dependency of GTK+ libraries on it. And this is
also why it's a bad idea to link in libpng statically when using wxGTK: as
you link with system libpng dynamically anyhow, you end up with 2 versions
of libpng in your process which may result in problems.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Fulvio Senore]

Il 11/06/2012 13.26, Vadim Zeitlin ha scritto:
> On Mon, 11 Jun 2012 10:37:44 +0200 Fulvio Senore wrote:
>
> FS> Now I have a problem with the png library: I have discovered that if I
> FS> build the image sample and I run "ldd image" I get (among others) the
> FS> following output line:
> FS>
> FS> libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb74fb000)
> FS>
> FS> so it looks like the program is still using the system libpng.
>
> This is due to an indirect dependency of GTK+ libraries on it. And this is
> also why it's a bad idea to link in libpng statically when using wxGTK: as
> you link with system libpng dynamically anyhow, you end up with 2 versions
> of libpng in your process which may result in problems.

Thank you, that explains the problem.
Is it the same for expat too?

I tried using the builtin libpng because a user reported that the
program did not start under OpenSUSE. It turned out that he had to
install libpng12 since his distro used another version.
Statically linking libpng looked like a solution, but now I understand
that it isn't.

It looks like there is no solution for such a problem, except for
building a package so that dependencies are well known. Unfortunately
building different packages for different distibutions would take a lot
of time.

Fulvio Senore

[Vadim Zeitlin]

On Mon, 11 Jun 2012 13:58:11 +0200 Fulvio Senore wrote:

FS> Is it the same for expat too?

I don't know, try running ldd on various GTK+ libraries to see if they
have a dependency on it.

FS> I tried using the builtin libpng because a user reported that the
FS> program did not start under OpenSUSE. It turned out that he had to
FS> install libpng12 since his distro used another version.
...
FS> It looks like there is no solution for such a problem

I wonder what would happened if you linked wxWidgets manually after
removing -lpng from the linker line and adding --allow-shlib-undefined
instead. I didn't test it but wouldn't this result in a version of the
library that wouldn't have any direct dependencies on libpng and so would
use whichever version is brought in via GTK instead?

[Fulvio Senore]

Il 11/06/2012 14.09, Vadim Zeitlin ha scritto:
>
> I wonder what would happened if you linked wxWidgets manually after
> removing -lpng from the linker line and adding --allow-shlib-undefined
> instead. I didn't test it but wouldn't this result in a version of the
> library that wouldn't have any direct dependencies on libpng and so would
> use whichever version is brought in via GTK instead?
>

Do you mean linking the wxWidgets library itself or a sample program
that uses wxWidgets? I am linking wxWidgets statically so there is no
linker stage, I suppose.

If I link the image sample I do not see any -lpng command. Here is the
linker line:

g++ -o image image_image.o image_canvas.o
-L/home/fulvio/wxSVN/buildgtk/lib -pthread -lwx_gtk2u_core-2.9
-lwx_baseu-2.9 -lwxtiff-2.9 -lwxjpeg-2.9 -lwxpng-2.9 -pthread
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm
-lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl
-lgthread-2.0 -lrt -lglib-2.0 -lX11 -lSM -lwxzlib-2.9 -lwxregexu-2.9
-lwxexpat-2.9 -pthread -ldl -lm -ldl -lm

Moreover the makefile compiles the source files with this command:

-I/usr/include/libpng12

so it looks like the code is compiled against the system png headers,
not the builtin ones.

Fulvio

[Vadim Zeitlin]

On Mon, 11 Jun 2012 17:46:39 +0200 Fulvio Senore wrote:

FS> Do you mean linking the wxWidgets library itself or a sample program
FS> that uses wxWidgets?

Linking wx itself if it's used as a shared library or your program if it
isn't.

FS> I am linking wxWidgets statically so there is no linker stage, I
FS> suppose.

Right.

FS> If I link the image sample I do not see any -lpng command. Here is the
FS> linker line:
FS>
FS> g++ -o image image_image.o image_canvas.o
FS> -L/home/fulvio/wxSVN/buildgtk/lib -pthread -lwx_gtk2u_core-2.9
FS> -lwx_baseu-2.9 -lwxtiff-2.9 -lwxjpeg-2.9 -lwxpng-2.9 -pthread
FS> -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm
FS> -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl
FS> -lgthread-2.0 -lrt -lglib-2.0 -lX11 -lSM -lwxzlib-2.9 -lwxregexu-2.9
FS> -lwxexpat-2.9 -pthread -ldl -lm -ldl -lm

Well, that's because you used --with-png=builtin. For my idea to have any
chance of working you have to use --with-png=sys (which is the default).

FS> Moreover the makefile compiles the source files with this command:
FS>
FS> -I/usr/include/libpng12

This probably comes from pkg-config output for GTK+.

FS> so it looks like the code is compiled against the system png headers,
FS> not the builtin ones.

The presence of -lwxpng-2.9 is a dead giveaway that the built-in version
is used.

[Fulvio Senore]

Il 11/06/2012 14.09, Vadim Zeitlin ha scritto:

> I wonder what would happened if you linked wxWidgets manually after
> removing -lpng from the linker line and adding --allow-shlib-undefined
> instead. I didn't test it but wouldn't this result in a version of the
> library that wouldn't have any direct dependencies on libpng and so would
> use whichever version is brought in via GTK instead?

I tested and the image sample linked without errors. The program still
loads the system libpng so I not sure to understand the difference.

Isn't GTK going to bring the installed copy of libpng? So this situation
to me looks the same as simply configuring wxWidgets to use the system
libpng.

Fulvio

[Vadim Zeitlin]

On Mon, 11 Jun 2012 19:02:26 +0200 Fulvio Senore wrote:

FS> Isn't GTK going to bring the installed copy of libpng? So this situation
FS> to me looks the same as simply configuring wxWidgets to use the system
FS> libpng.

I'm not sure but I hoped that by doing it like this you'd be able to build
on the system using libpng-1.2 but still run on the system with libpng-1.4
because the dependency on the exact libpng version would come from GTK
libraries which are different from system to system and not wx itself. But
of course you'd still use the system libpng, this is the whole point.

[Fulvio Senore]

Il 11/06/2012 20.03, Vadim Zeitlin ha scritto:
> On Mon, 11 Jun 2012 19:02:26 +0200 Fulvio Senore wrote:
>
> FS> Isn't GTK going to bring the installed copy of libpng? So this situation
> FS> to me looks the same as simply configuring wxWidgets to use the system
> FS> libpng.
>
> I'm not sure but I hoped that by doing it like this you'd be able to build
> on the system using libpng-1.2 but still run on the system with libpng-1.4
> because the dependency on the exact libpng version would come from GTK
> libraries which are different from system to system and not wx itself. But
> of course you'd still use the system libpng, this is the whole point.
>

Oh, now I understand. I'll have to install a distribution with
libpng-1.2 and test.

Thank you

Fulvio