You discovered a bug in the engine, and you are sure that it is not a problem of your code? Just post it in here. Please read the bug posting guidelines first.
The target sharedlib of the file source/Irrlicht/Makefile builds the shared library exporting many symbols that shall not be exported. wxGTK depends on libpng, and Irrlicht offers libpng's functions. So it will cause wxGTK to use the wrong version inside Irrlicht. What we need to do is to prohibit the libraries inside Irrlicht from exporting their symbols. Below is the patch for the Makefile.
$ objdump --dynamic-syms --demangle /usr/local/lib/libIrrlicht.so.1.8.1 | grep '\.text\>'
00219fb0 g DF .text 00000047 Base irr::io::createIrrXMLReaderUTF32(char const*)
0005a132 w DF .text 00000008 Base operator new(unsigned int, void*)
00219ff7 g DF .text 00000047 Base irr::io::createIrrXMLReaderUTF32(_IO_FILE*)
00219de6 g DF .text 0000009e Base irr::io::createIrrXMLReader(irr::io::IFileReadCallBack*, bool)
00219f12 g DF .text 0000009e Base irr::io::createIrrXMLReaderUTF16(irr::io::IFileReadCallBack*, bool)
00219e84 g DF .text 00000047 Base irr::io::createIrrXMLReaderUTF16(char const*)
00219ecb g DF .text 00000047 Base irr::io::createIrrXMLReaderUTF16(_IO_FILE*)
0021a03e g DF .text 0000009e Base irr::io::createIrrXMLReaderUTF32(irr::io::IFileReadCallBack*, bool)
00219d58 g DF .text 00000047 Base irr::io::createIrrXMLReader(char const*)
0024529a g DF .text 0000010f Base createDeviceEx
00245225 g DF .text 00000075 Base createDevice
00219d9f g DF .text 00000047 Base irr::io::createIrrXMLReader(_IO_FILE*)
Last edited by sgqfpu on Tue May 06, 2014 2:54 am, edited 2 times in total.
Ah ok, no problem. We add the [fixed] when we have fixed it in the engine. I hope Hybrid finds time for this one as he is usually more familiar with the Makefile than me. Otherwise I'll try to find some time to read up what this is about - but may take a while until I get to that (patch looks ok on first view, but have to figure out if that flag is always ok or if it maybe removes too many exports in some situations).
hendu wrote:FWIW, I have been using such since 2012 without issue.
It depends on how wxGTK is built and whether or not the wxGTK application uses wxJPEGHandler or wxPNGHandler. This incompatibility really may happen. For instance, when wxGTK needs to (indirectly) call function jpeg_CreateDecompress which is supposed to be offered by libjpeg, if libIrrlicht.so is in the list of /etc/ld.so.cache and the dynamic loader find the function in libIrrlicht.so first, then libIrrlicht.so will be used, instead of libjpeg.so. This is okay, if the libjpeg embedded inside libIrrlicht.so is the same version as the external libjpeg.so. But if they are not, then a runtime-error will happen "JPEG parameter struct mismatch: library thinks size is 444, caller expects 484". In the case of libpng.so, the message will be something like "Warning: Application built with libpng-1.2.49 but running with 1.5.9" and "Error: Couldn't load a PNG image - file is corrupted or not enough memory.", assuming the version number of the system-inherent is libpng-1.2.49.
Not wxgtk, I meant hidden symbols. But you really should use shared libs (you can toggle that in irrcompileconfig.h), otherwise your app is larger and slower than necessary.
Yeah, jpeglib (and other external libs) can be made to use system libs instead of Irrlicht's versions.
IIRC we agreed to not add the visibility flag some years ago as it introduced certain problems and could be added by the user at build-time easily. So we might postpone this until I checked all posts and changes regarding this issue
hendu wrote:Not wxgtk, I meant hidden symbols. But you really should use shared libs (you can toggle that in irrcompileconfig.h), otherwise your app is larger and slower than necessary.
I didn't noticed that there is a header file that affects which headers of other libraries are to be read by the compiler when building Irrlicht. Thank you, hendu. I did modify the Makefile, but did nothing to irrcompileconfig.h. So the result is weird. It read the headers offered by Irrlicht's source codes but linked against system libraries. Now I know I should have modified them both. Thanks again and sorry for the noise.
hybrid wrote:Yeah, jpeglib (and other external libs) can be made to use system libs instead of Irrlicht's versions.
IIRC we agreed to not add the visibility flag some years ago as it introduced certain problems and could be added by the user at build-time easily. So we might postpone this until I checked all posts and changes regarding this issue
Okay. Thanks for the work. Irrlicht is amazing. I love it.
BTW, on Windows, the exported symbol list the Dependency Walker shows is basically the same as the list the objdump shows on Linux, if -fvisibility=hidden. Without the option, the libIrrlicht.so.1.8 will export much more symbols than the counterpart dll in Windows.
Yeah, I know, and it should probably be the same for all systems. But I remember that several problems popped up when I tried it last time. But we will try to keep it in mind and hopefully solve it sometimes.