static linking issues

For help with general CEGUI usage:
- Questions about the usage of CEGUI and its features, if not explained in the documentation.
- Problems with the CMAKE configuration or problems occuring during the build process/compilation.
- Errors or unexpected behaviour.

Moderators: CEGUI MVP, CEGUI Team

RickP
Not too shy to talk
Not too shy to talk
Posts: 37
Joined: Sat Mar 13, 2010 03:52

Re: static linking issues

Postby RickP » Wed Mar 24, 2010 20:31

So I found the below code, but I'm thinking I can't have it both ways here. Because I want to statically link CEGUI to my DLL, but also want the CEGUI classes/methods exposed through my DLL as well. Yet you can't get the dllexport when static is defined. So if this is what I want is my only option to make a wrapper around the CEGUI stuff through my DLL? Because that would kind of suck and be very time consuming.

Code: Select all

#if (defined( __WIN32__ ) || defined( _WIN32 )) && !defined(CEGUI_STATIC)
#   ifdef CEGUIBASE_EXPORTS
#       define CEGUIEXPORT __declspec(dllexport)
#   else
#       define CEGUIEXPORT __declspec(dllimport)
#   endif
#       define CEGUIPRIVATE
#else
#       define CEGUIEXPORT
#       define CEGUIPRIVATE
#endif

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: static linking issues

Postby CrazyEddie » Wed Mar 24, 2010 21:04

Hmm. Some of the problem will also be that when you link statically, it will only bring in .o files from the archives that contain stuff you directly reference - so most of the CEGUI stuff is going to be discarded :?

The only (probably bad) idea I can come up with at the moment is to incorporate the relevant CEGUI sources along with your own code into a single DLL - this is no mean feat, but it can be done (brucey does a similar thing with the BlitzMax wrapper). This way you would dispense with all the linking issues and the problems of code getting thrown away when statically linking. The bad parts are that you'll need to somehow manage the build yourself - defining CEGUI_STATIC so the other DLLs are not required, but also exporting symbols from the main CEGUI code you're incorporating. It's definitely a hairy thing to attempt, but thinking over the issues again, perhaps the only viable solution?

CE.

RickP
Not too shy to talk
Not too shy to talk
Posts: 37
Joined: Sat Mar 13, 2010 03:52

Re: static linking issues

Postby RickP » Wed Mar 24, 2010 22:03

Hmm. Some of the problem will also be that when you link statically, it will only bring in .o files from the archives that contain stuff you directly reference - so most of the CEGUI stuff is going to be discarded


Really? I wasn't aware of that. So there is no way to tell it to bring it all in no matter what huh?

hmm, this should be fun then :)

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: static linking issues

Postby CrazyEddie » Thu Mar 25, 2010 09:58

Yeah, this is another 'plus' point for static linking - you only distribute the minimum object code required for the app to run. Perhaps in CEGUI it's not quite as bad as it seems, since the level of granularity is the .o / .obj file and some way or another CEGUI itself 'touches' a lot of it's own classes during initialisation.

I'm not sure how to force inclusion of all objects in a static archive. You could dump the objects from the archive(s) and pass them manually to the linker - not sure how to do that, or if it's feasible on MSVC++ - though again it's not your regular every day development task :)

CE.

jays
Not too shy to talk
Not too shy to talk
Posts: 27
Joined: Mon Apr 26, 2010 23:47

Re: static linking issues

Postby jays » Mon Apr 26, 2010 23:48

I believe if you put all the functions you want included in the same source file you'll always get them all.
-- Doctor Doctor, it hurts when I ....


Return to “Help”

Who is online

Users browsing this forum: No registered users and 10 guests