portable projects and .so/.dll linking

General questions regarding the usage of CodeLite
Modem Man
CodeLite Enthusiast
Posts: 28
Joined: Tue Sep 11, 2012 11:50 am
Genuine User: Yes
IDE Question: C++
Contact:

portable projects and .so/.dll linking

Post by Modem Man »

Dear,

I have a minor question of using same Codelite projects between Linux and Windows and some gory detail how the mingw differs from gcc and how this difference can best get handled with click-and-drop generated project files.
Lets assume a project which links a shared library "libFunctions.so" to an executable "MainProg". The same sources and Codelite project files are used with Linux and Windows, I share the same repository of version control system.

Basically, my ".so" file is made via

Code: Select all

gcc -c ./src/Functions.c -g  -o ./$(ConfigurationName)/Functions.o -I.
g++ -shared -fPIC -o ./$(ConfigurationName)/libFunctions.so ./$(ConfigurationName)/Functions.o -L.

and the executeable is made via

Code: Select all

g++ -c ./src/MainProg.cpp -g -O0 -Wall -o ./$(ConfigurationName)/MainProg.o -I./inc -I../Functions/inc
g++ -o ./$(ConfigurationName)/MainProg ./$(ConfigurationName)/MainProg.o -L./lib -L../Functions/Debug -lFunctions

It does well under Linux / Codelite 12 ... 15.

... BUT ...
when using a MinGW compiler under Win / Codelite (msys32 in my case, but apparently this detail does not matter), the Linker would not search for "libFunctions.so" when specifying -lFunctions. Instead, MinGW compiler would search "libFunctions.dll". But the Codelite generated project/makefiles are creating a "libFunctions.so".

Thus, in Windows environment I had to specify this "Post Build" step:

Code: Select all

	# copy .so to .dll because MinGW linker expects libXYZ.dll if statically linked -lXYZ, no .so as in linux
	cp $(OutputFile) $(OutDir)/lib$(ProjectName).dll

This additional line fixes the Windows linking problem and does no harm in Linux, except it pollutes my output folder. I hate pollution ;-)

Yes, another way would be to specify "-o ./$(ConfigurationName)/libFunctions.dll" in the makefile of the lib, but this entry is maintained by Codelite and the .dll extension would not get linked in Linux, I'd have to fix the inverse problem in Linux' post build step.

So my question #1 is:
Is there a more elegant way to force the ".so" extension to become ".dll" instead, but with still using the Codelite generated project/makefile and with having same project/makefile shared with Linux+Windows? Maybe something like ".$(SharedLibExtension)" or such?

My question #2 is about the ./$(ConfigurationName) which f.i. expands to either "./Debug" or "./Release": I really like using it, because I can easily toggle between full debug build or full release build of a project with linked sub projects. But I hate this lengthy "$(ConfigurationName)" name. Can I myself create an alias like $(Res) which has same meaning (and does not get overwritten by Codelite while maintaining the project files)?

Yes this questions are luxury problems, no urgency. But, hey, I'm using Codelite since years and almost all times all is well. How could I ask more urgent questions?
;-)

Cheers,
Modem Man

User avatar
eranif
CodeLite Plugin
Posts: 6367
Joined: Wed Feb 06, 2008 9:29 pm
Genuine User: Yes
IDE Question: C++
Contact:

Re: portable projects and .so/.dll linking

Post by eranif »

The linking line is taken from the compiler settings:

settings -> build settings
From the left view, select your compiler and the use the Template tabs.
At the bottom, there is a line that describes what will CodeLite use to link your DLL/SO.

For shared objects, CodeLite is using this:

Code: Select all

$(SharedObjectLinkerName) $(OutputSwitch)$(OutputFile) @$(ObjectsFileList) $(LibPath) $(Libs) $(LinkOptions)

You change that and use environment variables here.

Make sure you have read the HOW TO POST thread
Post Reply