Irrlicht Engine

Posted: **Mon May 05, 2014 3:15 pm**

The md5 of the source codes is

 
f4f7fa33bd1060eb0dd51dcd66b0f6e3  irrlicht-1.8.1.zip

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.

Code: Select all

 
--- source/Irrlicht/Makefile.original   2013-12-16 13:28:22.000000000 +0800
+++ source/Irrlicht/Makefile    2014-05-05 23:04:37.000000000 +0800
@@ -62,7 +62,7 @@
 ###############
 #Compiler flags
 CXXINCS = -I../../include -Izlib -Ijpeglib -Ilibpng
-CPPFLAGS += $(CXXINCS) -DIRRLICHT_EXPORTS=1
+CPPFLAGS += $(CXXINCS) -DIRRLICHT_EXPORTS=1 -fvisibility=hidden
 CXXFLAGS += -Wall -pipe -fno-exceptions -fno-rtti -fstrict-aliasing
 ifndef NDEBUG
 CXXFLAGS += -g -D_DEBUG

The result is...

Code: Select all

 
$ 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*)

Posted: **Mon May 05, 2014 5:25 pm**

Why is this topic already marked as [fixed]?

Posted: **Tue May 06, 2014 2:53 am**

CuteAlien wrote:Why is this topic already marked as [fixed]?

Sorry, I didn't know the convention here. I thought "fixed" means "having patch included".

Posted: **Tue May 06, 2014 10:35 am**

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).

Posted: **Wed May 07, 2014 6:59 am**

FWIW, I have been using such since 2012 without issue.

Posted: **Wed May 07, 2014 9:41 am**

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.

Posted: **Wed May 07, 2014 9:42 am**

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.

Posted: **Wed May 07, 2014 4:05 pm**

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

Posted: **Sat May 10, 2014 3:02 pm**

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.

Posted: **Sat May 10, 2014 3:16 pm**

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.

Posted: **Sat May 10, 2014 4:28 pm**

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.

Irrlicht Engine

Incompatible with wxGTK

Incompatible with wxGTK

Re: [fixed] Incompatible with wxGTK

Re: [fixed] Incompatible with wxGTK

Re: Incompatible with wxGTK

Re: Incompatible with wxGTK

Re: Incompatible with wxGTK

Re: Incompatible with wxGTK

Re: Incompatible with wxGTK

Re: Incompatible with wxGTK

Re: Incompatible with wxGTK

Re: Incompatible with wxGTK