A wierd (to me at any rate) linker problem
I'm trying to compile gnuplot 4.6.1, but it breaks on a library item being linked - file not found. Except it is clearly there. Details: [src]> c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -L/usr/lib -o gnuplot alloc.o axis.o binary.o breaders.o color.o command.o contour.o datafile.o dynarray.o eval.o fit.o gadgets.o getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o interpol.o matrix.o misc.o mouse.o parse.o plot.o plot2d.o plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o specfun.o standard.o stats.o stdfn.o tables.o tabulate.o term.o time.o unset.o util.o util3d.o variable.o version.o -lcurses -ledit -lz -lgd -lXpm -lX11 -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm -ljpeg -llua -lm -ldl -lm /usr/bin/ld: cannot find -lpng12 collect2: ld returned 1 exit status [src]> [src]> ls -l /usr/lib/libpng12.so.0 lrwxrwxrwx 1 root root 18 May 13 21:09 /usr/lib/libpng12.so.0 -> libpng12.so.0.49.0 [src]> OK, there's libpng15 there also, change the 2 to a 5 in the above, and LO! the link works. Maybe libpng12 didn't get picked up by ldconfig: [/etc]> strings ld.so.cache | grep libpng libpng15.so.15 /usr/lib/libpng15.so.15 libpng15.so /usr/lib/libpng15.so libpng12.so.0 /usr/lib/libpng12.so.0 libpng.so.3 /usr/lib/libpng.so.3 [/etc]> Well that looks good to me. Where to next?
On Mon, May 13, 2013 at 9:40 PM, Allan Duncan <amd2345@fastmail.com.au> wrote:
I'm trying to compile gnuplot 4.6.1, but it breaks on a library item being linked - file not found. Except it is clearly there. Details:
So the linker could not find the file. First of all, see what the linker knows about. Run the following to print the libraries that the linker has in its cache: `ldconfig -p | grep libpng' -Matt
On 13/05/13 22:30, Matt Davis wrote:
ldconfig -p | grep libpng
libpng15.so.15 (libc6) => /usr/lib/libpng15.so.15 libpng15.so (libc6) => /usr/lib/libpng15.so libpng12.so.0 (libc6) => /usr/lib/libpng12.so.0 libpng.so.3 (libc6) => /usr/lib/libpng.so.3 Ah-ha. I hadn't noticed before - libpng12 only exists as libpng12.so.0 - there is no bare libpng12.so Not sure why - the libpng15 doesn't have /usr/lib/libpng15.so in the rpm either, it is generated by a script on installation.
On Tue, May 14, 2013 at 07:06:59PM +1000, Allan Duncan wrote:
On 13/05/13 22:30, Matt Davis wrote:
ldconfig -p | grep libpng
libpng15.so.15 (libc6) => /usr/lib/libpng15.so.15 libpng15.so (libc6) => /usr/lib/libpng15.so libpng12.so.0 (libc6) => /usr/lib/libpng12.so.0 libpng.so.3 (libc6) => /usr/lib/libpng.so.3
Ah-ha. I hadn't noticed before - libpng12 only exists as libpng12.so.0 - there is no bare libpng12.so
Not sure why - the libpng15 doesn't have /usr/lib/libpng15.so in the rpm either, it is generated by a script on installation.
I suspect the answer is: you have libpng12 et al as runtime support for old programs. The devel package you have installed is libpng15. The header files in /usr/include are designed for use with png15. If you force-load png12 (by making the symlink /usr/lib/libpng12.so) there is no guarantee that the API will match the header files. So, you should be loading with -lpng15. If you *need* to build a png12 app, you should upgrade to png12 devel, which will (or should) delete /usr/lib/libpng15.so). Hope this helps, Cheers ... Duncan. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
On 14/05/13 20:50, Duncan Roe wrote:
On Tue, May 14, 2013 at 07:06:59PM +1000, Allan Duncan wrote:
On 13/05/13 22:30, Matt Davis wrote:
ldconfig -p | grep libpng
libpng15.so.15 (libc6) => /usr/lib/libpng15.so.15 libpng15.so (libc6) => /usr/lib/libpng15.so libpng12.so.0 (libc6) => /usr/lib/libpng12.so.0 libpng.so.3 (libc6) => /usr/lib/libpng.so.3
Ah-ha. I hadn't noticed before - libpng12 only exists as libpng12.so.0 - there is no bare libpng12.so
Not sure why - the libpng15 doesn't have /usr/lib/libpng15.so in the rpm either, it is generated by a script on installation.
I suspect the answer is: you have libpng12 et al as runtime support for old programs. The devel package you have installed is libpng15. The header files in /usr/include are designed for use with png15. If you force-load png12 (by making the symlink /usr/lib/libpng12.so) there is no guarantee that the API will match the header files. So, you should be loading with -lpng15. If you *need* to build a png12 app, you should upgrade to png12 devel, which will (or should) delete /usr/lib/libpng15.so).
Hope this helps,
Cheers ... Duncan.
No, the gnuplot 4.6 build explicitly requests libpng12. I have both png15 and png12-compat installed. The cure was to make a symlink for libpng12.so to libpng12.so.0 and rerun ldconfig. Now "ldconfig -p | grep libpng" gives libpng15.so.15 (libc6) => /usr/lib/libpng15.so.15 libpng15.so (libc6) => /usr/lib/libpng15.so libpng12.so.0 (libc6) => /usr/lib/libpng12.so.0 libpng12.so (libc6) => /usr/lib/libpng12.so libpng.so.3 (libc6) => /usr/lib/libpng.so.3
On Tue, May 14, 2013 at 10:59:09PM +1000, Allan Duncan wrote:
On 14/05/13 20:50, Duncan Roe wrote:
On Tue, May 14, 2013 at 07:06:59PM +1000, Allan Duncan wrote:
On 13/05/13 22:30, Matt Davis wrote:
ldconfig -p | grep libpng
libpng15.so.15 (libc6) => /usr/lib/libpng15.so.15 libpng15.so (libc6) => /usr/lib/libpng15.so libpng12.so.0 (libc6) => /usr/lib/libpng12.so.0 libpng.so.3 (libc6) => /usr/lib/libpng.so.3
Ah-ha. I hadn't noticed before - libpng12 only exists as libpng12.so.0 - there is no bare libpng12.so
Not sure why - the libpng15 doesn't have /usr/lib/libpng15.so in the rpm either, it is generated by a script on installation.
I suspect the answer is: you have libpng12 et al as runtime support for old programs. The devel package you have installed is libpng15. The header files in /usr/include are designed for use with png15. If you force-load png12 (by making the symlink /usr/lib/libpng12.so) there is no guarantee that the API will match the header files. So, you should be loading with -lpng15. If you *need* to build a png12 app, you should upgrade to png12 devel, which will (or should) delete /usr/lib/libpng15.so).
Hope this helps,
Cheers ... Duncan.
No, the gnuplot 4.6 build explicitly requests libpng12. I have both png15 and png12-compat installed.
The cure was to make a symlink for libpng12.so to libpng12.so.0 and rerun ldconfig. Now "ldconfig -p | grep libpng" gives libpng15.so.15 (libc6) => /usr/lib/libpng15.so.15 libpng15.so (libc6) => /usr/lib/libpng15.so libpng12.so.0 (libc6) => /usr/lib/libpng12.so.0 libpng12.so (libc6) => /usr/lib/libpng12.so libpng.so.3 (libc6) => /usr/lib/libpng.so.3
Yes I suggested to make that symlink earlier. THe output from ldconfig is *irrelevant* to getting a good build - it is *only* used by /lib/ld-linux.so.* when starting an executable (/lib64 for 64-bit). Glad to hear you got it sorted anyway, Cheers ... Duncan. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
On Mon, May 13, 2013 at 09:40:29PM +1000, Allan Duncan wrote:
I'm trying to compile gnuplot 4.6.1, but it breaks on a library item being linked - file not found. Except it is clearly there. Details:
[src]> c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -L/usr/lib -o gnuplot alloc.o axis.o binary.o breaders.o color.o command.o contour.o datafile.o dynarray.o eval.o fit.o gadgets.o getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o interpol.o matrix.o misc.o mouse.o parse.o plot.o plot2d.o plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o specfun.o standard.o stats.o stdfn.o tables.o tabulate.o term.o time.o unset.o util.o util3d.o variable.o version.o -lcurses -ledit -lz -lgd -lXpm -lX11 -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm -ljpeg -llua -lm -ldl -lm /usr/bin/ld: cannot find -lpng12 collect2: ld returned 1 exit status [src]>
[src]> ls -l /usr/lib/libpng12.so.0 lrwxrwxrwx 1 root root 18 May 13 21:09 /usr/lib/libpng12.so.0 -> libpng12.so.0.49.0 [src]>
OK, there's libpng15 there also, change the 2 to a 5 in the above, and LO! the link works. Maybe libpng12 didn't get picked up by ldconfig:
[/etc]> strings ld.so.cache | grep libpng libpng15.so.15 /usr/lib/libpng15.so.15 libpng15.so /usr/lib/libpng15.so libpng12.so.0 /usr/lib/libpng12.so.0 libpng.so.3 /usr/lib/libpng.so.3 [/etc]>
Well that looks good to me.
Where to next? _______________________________________________
Things to look for include - libpng12.so.0 is 32-bit and you need 64 (or vice versa) - libpng12.so.0 is libc5 - /usr/lib/libpng12.so does not exist - /usr/lib/libpng12.so points to something else The output you posted suggests to me the 3rd option above. ld does not use ld.so.conf: that is runtime only. ld needs .so files Cheers ... Duncan. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
Allan Duncan <amd2345@fastmail.com.au> writes:
I'm trying to compile gnuplot 4.6.1, but it breaks on a library item being linked - file not found. Except it is clearly there. Details:
[src]> c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -L/usr/lib -o gnuplot alloc.o axis.o binary.o breaders.o color.o command.o contour.o datafile.o dynarray.o eval.o fit.o gadgets.o getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o interpol.o matrix.o misc.o mouse.o parse.o plot.o plot2d.o plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o specfun.o standard.o stats.o stdfn.o tables.o tabulate.o term.o time.o unset.o util.o util3d.o variable.o version.o -lcurses -ledit -lz -lgd -lXpm -lX11 -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm -ljpeg -llua -lm -ldl -lm
Does that match what pkg-config says you should use?
On Mon, 13 May 2013, Allan Duncan <amd2345@fastmail.com.au> wrote:
/usr/bin/ld: cannot find -lpng12 collect2: ld returned 1 exit status [src]>
[src]> ls -l /usr/lib/libpng12.so.0 lrwxrwxrwx 1 root root 18 May 13 21:09 /usr/lib/libpng12.so.0 -> libpng12.so.0.49.0
Does the file it links to exist and have the correct contents? Have you run the command your distribution uses to verify the checksums of the files in question? You could run "strace -s 2000 -o ~/tmp/gcc-trace -ff c++ ..." and then look through the trace to see what happened before the error. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
participants (5)
-
Allan Duncan -
Duncan Roe -
Matt Davis -
Russell Coker -
trentbuck＠gmail.com