Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Build C::B against wx3.02 with gcc 5.2 under Windows

<< < (22/25) > >>

mageia:
it is awesome then only denpend on codeblocks.dll,i can't build 10561,link error about wx_MSLU_stat(?)

ollydbg:

--- Quote from: mageia on November 08, 2015, 09:44:43 am ---it is awesome then only denpend on codeblocks.dll,i can't build 10561,link error about wx_MSLU_stat(?)

--- End quote ---
Please give use details about your problem.

oBFusCATed:

--- Quote from: ollydbg on November 07, 2015, 03:24:19 pm ---...
Any one know how to remove such warning?
...

--- End quote ---
You have to add a using directive for the function in the parent class. If our function does something special and using the original function is not a good idea you can put the using directive in the private/protected section.

ollydbg:

--- Quote from: ollydbg on November 06, 2015, 02:00:10 pm ---
--- 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.

--- End quote ---
OK.
I have done the patches, which let some plugins link to the static library. So the symbols in those static libraries are not exported from the codeblocks.dll, see the patches here: Link

mageia:

--- Quote from: ollydbg on November 08, 2015, 12:16:05 pm ---
--- Quote from: mageia on November 08, 2015, 09:44:43 am ---it is awesome then only denpend on codeblocks.dll,i can't build 10561,link error about wx_MSLU_stat(?)

--- End quote ---
Please give use details about your problem.

--- End quote ---
thanks reply,and here is

--- Quote ---C:\localusr\wxWidgets\include\wx\filefn.h|522|undefined reference to `wxMSLU__wstat(wchar_t const*, _stat64*)'|
||error: ld returned 1 exit status|
--- End quote ---
MSLU ,wx use it on win9.x not later,isn't it,error happen when link codeblocks.dll,and i use nuwen's mingw64 to build wx3.02 and codeblocks 10561,enough information or not?

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version