Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Build C::B against wx3.02 with gcc 5.2 under Windows
oBFusCATed:
--- Quote from: ollydbg on October 30, 2015, 01:11:15 pm ---Under Windows, all the static libraries are build with all symbol exported(Note this option is enabled by default), and later those symbols were exported through codeblocks.dll(the sdk target). That's the current way we have used for many years.
I have said that before in this thread. Those kinds of static libraries are quite similar as shared libraries. And you will see that all the plugins are only need to link the the codeblocks.dll, and they don't need static to link to tinyxml like libraries.
My change on those static libraries is that I use explicitly symbol export, which means all the symbols needed to export from the codeblocks.dll is need to be decorated as "__declspec(dllexport)", This reduce the export table of the codeblocks.dll, and make resolution of the symbols a bit faster.
--- End quote ---
Yes, I know and I say this is the wrong way to do it.
All these libs have not been designed to be shared libraries.
If they are we should just build them as such and don't bother with all this trickery.
Also on linux using the default visibility can cause lots of problems and strange crashes.
ollydbg:
--- Quote from: oBFusCATed on October 31, 2015, 01:03:07 am ---
--- Quote from: ollydbg on October 30, 2015, 01:11:15 pm ---Under Windows, all the static libraries are build with all symbol exported(Note this option is enabled by default), and later those symbols were exported through codeblocks.dll(the sdk target). That's the current way we have used for many years.
I have said that before in this thread. Those kinds of static libraries are quite similar as shared libraries. And you will see that all the plugins are only need to link the the codeblocks.dll, and they don't need static to link to tinyxml like libraries.
My change on those static libraries is that I use explicitly symbol export, which means all the symbols needed to export from the codeblocks.dll is need to be decorated as "__declspec(dllexport)", This reduce the export table of the codeblocks.dll, and make resolution of the symbols a bit faster.
--- End quote ---
Yes, I know and I say this is the wrong way to do it.
All these libs have not been designed to be shared libraries.
If they are we should just build them as such and don't bother with all this trickery.
Also on linux using the default visibility can cause lots of problems and strange crashes.
--- End quote ---
As you suggested, we need to build them as static libraries, and we need to link them as static libraries. A lot of targets need those static libraries, for example, if some plugin need to access the configure file, then we need to link to the static version of the tinyxml library.
Am I right?
If we see this is the correct direction, I may take some time to test it.
EDIT: what I want to commit are such commits which only add the "DLLIMPORT" macros to the symbols, such as:
- add DLLIMPORT decoration. ยท obfuscated/codeblocks_sf@c3453df, this won't change any build target. What's your opinion?
oBFusCATed:
Yes, adding DLLIMPORT to classes in the sdk or in the include folders is safe and I have no objections, so go on and commit them.
ollydbg:
--- Quote from: oBFusCATed on November 06, 2015, 08:41:51 pm ---Yes, adding DLLIMPORT to classes in the sdk or in the include folders is safe and I have no objections, so go on and commit them.
--- End quote ---
Done in trunk. :)
oBFusCATed:
Why do you need to export the InfoPane class?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version