Jump to content
  • Advertisement
Sign in to follow this  
JensE

Are static libs platform-independent?

This topic is 5407 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I ask this question because in Visual C++ you can only create a "Win 32 static library". So I've got some questions about static libs: (1) Usage of static libs is restricted to Windows platforms? (2) Can one export classes with static libs, are other C++ features (templates...) supported? (3) Which size is appropriate for static libs? I know that they're compiled directly into the executable. So I suppose little components should be made to libs, larger components to dlls or is it generally a good choice to use static libs? (4) What does this error mean (I cannot exactly remember it): "Standard library "LIBC.LIB" conflicts with other libraries." What does it mean exactly and what can I do to make it disappear? (5) Are there any other known problems or issues with static libs you would like to tell me about? Thank you very much for your answers!!!

Share this post


Link to post
Share on other sites
Advertisement
1) Static libraries are platform dependent. Different platforms have different archive formats and ABI's.

2) Templates are translated into type-specific code at compile time, so you must make available the necessary code.

3) This is application-dependent. Generally you wouldn't be using static binaries if you were concerned with size.

4) Most likely some object file in your project has a symbol with the same name as one in libc.lib, or libc is being linked twice.

Share this post


Link to post
Share on other sites
2) You can export classes. This includes specific template instanciations.

4) Odds are the libraries you are linking expect to be dynamically linked to the C run-time. LIBC.LIB is the static library version. Change your project options accordingly.

Share this post


Link to post
Share on other sites
"Static libraries are platform dependent. Different platforms have different archive formats and ABI's."

So there is no easy way to export code using platform-independent methods?
Every professor tells us we should make our code highly-portable and platform independent, but it seems to be a really hard work to do!
So I guess a developer must compile for each platform he wants to support, dlls and libs for Win32, and whatever for the other operating systems?

Share this post


Link to post
Share on other sites
If you stick to standard C/C++ and avoid making platform specific assumptions (like alignment/word sizes), then the code that you write can be compiled on any platform with a C/C++ compiler. That is what your professor means by portable and platform independent code.

Share this post


Link to post
Share on other sites
All (major) platforms support dynamic and static libraries in some way. For dynamic libraries Windows uses DLLs, Unix uses shared objects (.so), and MacOS uses something else.

For static libraries, Windows uses .libs, and Unix uses .a files. However, from a code standpoint, a Win32 shared library can be compiled as a Unix library with no changes (unless you use platform-dependant code, of course - so avoid windows.h).

For dynamic libraries, .so files and DLLs are somewhat different, and you may need to make some changes, but it is fully possible to support both with some use of #ifdef and the build system. A Unix .so is really the same as a .a, with different commands passed to the linker. A Win32 DLL requires symbols to be exported; a Unix .so exports all symbols automatically.

I have both setups in my current project and it works just fine.

Share this post


Link to post
Share on other sites
Ok, thank you, the platform independance issue seems to be clear now.

But one more thing: I've got the following components:
- Maths (helper functions like fast sine, some makros et cetera)
- WinAPIUtils (some WinAPI helper functions, I know, not platform-independent :))
- StringUtils (no need to explain this)
- Err (some error codes and error display functions)

I compiled that ones to static libs, because they're not very big and I didn't want to make the effort with dlls.

What about this components:
- Library for linear algebra including 2x2-, 3x3- and 4x4-Matrices, 2D, 3D, 4D vectors, planes, 3D lines and quaternions
- Enum: kind of render API independent graphics hardware enumeration component.

They're a lot bigger than the others mentioned before. I made them to dlls, because I know, they've got advantages considering updating aspects, and they would make the executable too large. A good choice?

Is there another option instead of static libs / dlls on windows platforms?

Share this post


Link to post
Share on other sites
Quote:
Original post by JensE
What about this components:
- Library for linear algebra including 2x2-, 3x3- and 4x4-Matrices, 2D, 3D, 4D vectors, planes, 3D lines and quaternions
- Enum: kind of render API independent graphics hardware enumeration component.

They're a lot bigger than the others mentioned before. I made them to dlls, because I know, they've got advantages considering updating aspects, and they would make the executable too large. A good choice?
The LinAlg stuff should probably be in a static library (actually, it could just be in a set of headers to take advantage of inlining), since it's never going to be changed. Think about it - the rules of algebra haven't changed in 300 years, so why should your LinAlg library have to?

As for the Enum stuff, it probably doesn't make a difference.

Also, never underestimate the abilities of a modern optimizing compiler. They can do wonderful things. Using DLLs can make things bigger, since every exported symbol must remain in the DLL, but with a static lib the linker will remove any unused symbols from the resulting executable.

Quote:
Original post by JensE
Is there another option instead of static libs / dlls on windows platforms?
.NET assemblies, which have the entirely logical extension of '.dll', even though they aren't. But you really need C# or VB or C++/CLR to use those.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!