Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
Hi all, I'm rather new to cpptasks, so I might be missing a linker option (though I _have_ looked through the available documentation)... the problem is:
I can successfully compile numerous cpp files to objects and build them as libraries but I receive errors when trying to build an executable that links to those libraries.
More specifically, when a cc target that needs to link with a library is called, cpptasks *appears* to call libtool with the option "-Bstatic" or "-Bdynamic" depending on the library type, when these are not options to the OSX libtool.
My build script does work correctly on Linux and Unix, just not on OSX. However, I can manually enter the corresponding terminal command ("g++ -I./include -I./utilities/include src/main.cpp -L./libs -L./utilities/libs -lmgp -lutilities") with correct results.
<target name="mgp-exec" depends="all-static, utilities">
<libset libs="stdc++" if="is-gcc"/>
Do things work correctly if you remove the type="static" from the libset elements?
Do you have both shared and static libraries for mgp and utilities so that it is necessary to specify which to use?
Are you suggesting that OS/X builds ignore type="static"?
Thanks for the heads-up. I can't look into it immediately with tax filings due next week.
Thx, things appear workable if the explicit type="static" is removed from the libset element.
I did have both shared and static libraries for both of my linkable targets (mgp and utilities), as certain later stages required each. I think it should be workable to build static versions of those libraries, compile any executables, then generate any needed shared objects.
I'm not suggesting OSX builds of cpptasks ignore type="static" elements, but that the generated console behavior [SharedObjects: "libtool -Bstatic"] and [executables: "ld -Bstatic"] (and similarly for "-Bdynamic") is not understood by darwin's libtool or ld.
For my own uses, the above workaround on dependency-orderings will suffice, but fixing the error might be as simple as changing "-Bstatic/-Bdynamic" to "-static/-dynamic", as GNU gcc/ld interprets Bstatic/static and Bdynamic/dynamic identically.
If I find some extra time, I'll try and take a deeper look at net.sf.antcontrib.cpptasks.gcc.AbstractLDLinker
-- good luck with taxes ;-)