Re: [Imtoolkit-users] libpng link problem on Linux (Ubuntu 18.04 LTS)

[Matthew K. <bur...@gm...>]

Thanks, Antonio. That makes sense.

Matt

On Tue, May 28, 2019 at 4:44 PM Antonio Scuri <ant...@gm...>
wrote:

>   Hi,
>
>   We don't link with libPNG because of GTK. Since it uses libPNG, if your
> program uses GTK it already loads libPNG and it loads the correct lib
> compatible with GTK.
>
>   So if you don't use GTK, then you must explicitly link with
> libPNG using LIBS += png. It is not necessary to link with the version
> number. When the libpng-dev package is installed a link is created to point
> to the file with the version number.
>
> Best,
> Scuri
>
>
> Em ter, 28 de mai de 2019 às 18:32, Matthew Kennedy <bur...@gm...>
> escreveu:
>
>> Hi,
>>
>> On Linux, it looks like the build system is designed to use the system
>> libpng, but the resulting libim.so doesn't link against it:
>>
>> /tmp/im-3.13_Linux415_64_lib$ ldd libim.so
>>         linux-vdso.so.1 (0x00007fff207bd000)
>>         libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f58218b4000)
>>         libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>> (0x00007f582152b000)
>>         libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f582118d000)
>>         libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
>> (0x00007f5820f75000)
>>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5820b84000)
>>         /lib64/ld-linux-x86-64.so.2 (0x00007f5821e28000)
>>
>> #include <stdio.h>
>> #include <dlfcn.h>
>> int main(int argc, char **argv) {
>>   void *result = dlopen(argv[1], RTLD_NOW);
>>   if (! result) {
>>     printf("error: %s\n", dlerror());
>>   }
>>   return 0;
>> }
>> // gcc -Wall -Werror testload.c -o testload -ldl
>>
>> /tmp/im-3.13_Linux415_64_lib$ ~/Projects/testload $PWD/libim.so
>> error: /tmp/im-3.13_Linux415_64_lib/libim.so: undefined symbol:
>> png_get_sRGB
>>
>> I also checked building from SVN and get the same result.
>>
>> I think where the build system is doing LIBS += png, it should do
>> something like LIBS += png16 (at least on Ubuntu 18.04), but I'm not sure
>> if that's legit for all distros.
>>
>> I can work around it by patching the libim.so shared object though:
>>
>> /tmp/im-3.13_Linux415_64_lib$ patchelf --add-needed libpng16.so.16
>> libim.so
>> /tmp/im-3.13_Linux415_64_lib$ ~/Projects/testload $PWD/libim.so
>>
>> /tmp/im-3.13_Linux415_64_lib$ ldd libim.so
>>         linux-vdso.so.1 (0x00007fffc4f4f000)
>>         libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16
>> (0x00007f0205a91000)
>>         libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f0205874000)
>>         libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>> (0x00007f02054eb000)
>>         libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f020514d000)
>>         libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
>> (0x00007f0204f35000)
>>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0204b44000)
>>         /lib64/ld-linux-x86-64.so.2 (0x00007f0206022000)
>>
>> At this point, I can load the shared object (and invoke PNG related
>> things, in Lisp, in my example):
>>
>> CL-USER> (im-file:image-load
>> "/usr/share/backgrounds/Beaver_Wallpaper_Grey_4096x2304.png")
>> #<TECGRAF-BASE:IM-IMAGE {100249FBB3}>
>>
>> The Windows builds do not have this problem.
>>
>> Matt
>>
>>
>> _______________________________________________
>> Imtoolkit-users mailing list
>> Imt...@li...
>> https://lists.sourceforge.net/lists/listinfo/imtoolkit-users
>>
> _______________________________________________
> Imtoolkit-users mailing list
> Imt...@li...
> https://lists.sourceforge.net/lists/listinfo/imtoolkit-users
>