0

I have a C++ project that can be compiled with -D UNICODE.

When I compile it without that Define, it creates a bunch of object files which I then add to a .a archive file using the command: ar.exe rcs Cpplib.a *.o

Then I compile it with that define and archive the objects using: ar.exe rcs CpplibU.a *.o

where the U states that the archive is a Unicode one.

Is there a way I can combine both .a files into ONE archive so that I can link to that instead of having to link to:

Cpplib_x32.a Cpplib_x64.a Cpplib_x32U.a Cpplib_x64U.a

Now I don't mind linking to x32 and x64 separately but having to link to 2 x64's and 2 x32's is kinda annoying.

I want to know if there is a way I can either combine the x32 and x64 archives OR combine the Non-Unicode and Unicode archives. I don't need both. Either, Or.

Any ideas or am I stuck having to link to all 4?

Brandon
  • 22,723
  • 11
  • 93
  • 186
  • "*instead of having to link to:*" How could you be linking to all of those anyway? They're mutually exclusive, yes? If you're compiling for 32-bit, you can't link to libraries built with a 64-compilation. And if you're compiling for Unicode, linking to non-Unicode compiled libraries is dangerous. Like linking to libraries compiled for debug in a release build or vice-versa. – Nicol Bolas May 24 '13 at 21:36
  • No sir. I linked to all of them and Mingw/Codeblocks allows it. It only uses the one that fits. In other words, if I'm compiling a project without Unicode, Mingw somehow knows to use the Non-Unicode one and ignore the others all without bloating my exe/lib or throwing compilation/runtime errors.. It also does this for the x32/x64 ones.. I don't know how but it compiles and runs just fine.. I just didn't want to link to that many.. Rather link to one that contains all four in it or two that contains their unicode counterparts. If I compile the x32 program without linking x64, it won't compile. – Brandon May 24 '13 at 21:40
  • "*I don't know how but it compiles and runs just fine.*" If you don't know how it works, then you don't know *that* it works. All you know is that you've tried it and nothing has apparently broken. I'm not saying that GCC can't handle it. I'm saying that it has been my experience that linking to code that was compiled with *different* system `#defines` usually leads to badness. – Nicol Bolas May 24 '13 at 21:45
  • That's a typing error.. I couldn't edit the comment because it says comments can only edit before 5 minute marker.. I meant to say: If I compile x32 without x32 libs, it will not compile. Or if I compile x64 without using x64 libs (vice-versa), it won't compile. Unicode without Unicode libs won't compile either. Non-Unicode with Unicode libs won't compile. So yeah the compiler is handling it well. – Brandon May 24 '13 at 21:47

1 Answers1

2

If the symbol names and object filenames are different, then you can have at least all the 32-bit code and all the 64-bit code in a library of it's own. And of course, a makefile can easily create an object file called xxA.o and xxU.o or something like that for the ASCII vs. UNICODE variant.

If the symbol names are the same (which they will be for functions that, for example, don't take a parameter and have the same return type, or extern "C" functions, as they are not name-mangled based on parameters), then you can't use this method [or have multiple libraries that supply that function, so supplying a whole long list of libraries also won't work].

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • I will accept this but my question to you sir is: If I have two files - FooA.o and FooU.o and both files contains a function: 'void GetString(tString)' where tString is an #ifdef unicode string. Ex: If unicode is defined, tstring is std::wstring and if Unicode is not defined its a std::string. Can I add both those files to one archive and just supply the header? Ex: http://pastebin.com/xyaRLWd6 – Brandon May 24 '13 at 21:59
  • 1
    In C++ those will have different names. If they are `extern "C"` type functions then you will get whichever the linker finds first [almost certainly the one in the first library]. But then you probably can't use `tString` as an argument for a C style function. If in doubt, use `nm FooA.o` and compare it with `nm FooU.o` to see what the names are. – Mats Petersson May 24 '13 at 22:06