• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
fir

lib hell

12 posts in this topic

Im not quite see it clearly (got not so much experience) and maybe some will help me to claryfy this picture

 

Im mostly talking about windows platform (though I may be courious if on other platforms things looks better)

 

As far as i know there is no standarisation of lib (static libraries format)

so there we got some static lib-hell (my own name for this) where given static lib may only works with some compiler say VS or say GCC and not across them all (as it should be) [I am speeking on one specyfic system

mostly win32 or win64]

 

1) is this true?

2) do this incompatibility occur between across verisons of compilers 

or it only occurs between different compilers (I mean can lib not works if 

made with older version of compiller with the newer version of the same 

brand compiler or in one compiler it will work for all verions)

3) are the gcc/vs/intel/what else partially compatible - or in general mostly not compatible

4) is there a way of mending a incompatible lib in some way ?

 

tnx for the answer (it seem to me tah it may be hard to answer thiss fully but at least partially - i would like to build some wiev on this static lib - hell  in windows, how the things look like)

 

 

 

0

Share this post


Link to post
Share on other sites
I would strongly advise compiling a static library with the exact compiler and the exact build settings you intend to use it with. You might be able to work without that provided you have a pure C library, but I don't have significant experience in that area.

As soon as C++ enters the picture it's just not worth it. Even for the same version of the same compiler setting a different flag can break ABI-compatibility (for example the safe iterator define on earlier MSVCs would do that). That can lead to extremely annoying, very subtle, hell to find problems.
On the other hand the Windows version of gcc had one or two (unintentional) ABI breaks some time between 4.8.0 to 4.8.2. Check the changelogs for details.

Also note that is not a problem limited to static libraries. Unless you can make several restrictions regarding choice of runtime and other build settings an interface between dynamic libraries is also extremely limited (regarding allowed types and memory ownership).

On Windows you can usually get around compiling your own libraries if you stick to MSVC and you do not divert from the standard 'Debug' and 'Release' configurations. I would still suggest you get into the habit of compiling your own libraries though. You will need it sooner or later anyway and it's better to get skill points in compile-foreign-code without a really nasty deadline at your back.
2

Share this post


Link to post
Share on other sites

1) is this true?

Yes.

2) do this incompatibility occur between across verisons of compilers 
or it only occurs between different compilers (I mean can lib not works if 
made with older version of compiller with the newer version of the same 
brand compiler or in one compiler it will work for all verions)

Incompatibilities between different compilers are quite likely. It may work when using only different version of the same compiler (VS doesn't allow it though, don't know about other compilers).

3) are the gcc/vs/intel/what else partially compatible - or in general mostly not compatible

From what I know Intel is compatible with VS (not vice versa though). And I was able to use a MSVC dll with MinGW, however in most cases this will not work properly.

4) is there a way of mending a incompatible lib in some way ?

If you have access to the source code you may try to compile it with the compiler you need. If you don't have the source you are out of luck in the most cases.
1

Share this post


Link to post
Share on other sites

As far as i know there is no standarisation of lib (static libraries format)

 

*.lib/a file is just an archive that contains *.obj files (+ eventually some minimalistic metadata header file). 

EDIT: And those obj files are passed to the linker. So YES the sample compilation settings is a *MUST(only few exceptions are possible. I personally don't allow them in my build system, It is obvious that they will make you kill yourself).

Edited by imoogiBG
1

Share this post


Link to post
Share on other sites

Im not quite see it clearly (got not so much experience) and maybe some will help me to claryfy this picture
 
Im mostly talking about windows platform (though I may be courious if on other platforms things looks better)
 
As far as i know there is no standarisation of lib (static libraries format)
so there we got some static lib-hell (my own name for this) where given static lib may only works with some compiler say VS or say GCC and not across them all (as it should be) [I am speeking on one specyfic system
mostly win32 or win64]
 
1) is this true?

 
simple answer: yes.
 
 
less simple answer: there is some informal/de-facto standardization of LIB and OBJ file-formats, at least as far as Windows goes (as AR archives and COFF objects, known as OBJ/LIB with MSVC and O/A with GCC). however different compilers have various minor format differences (in terms of structures both within LIB/AR and the COFF objects), making things problematic.

some compilers had also used different formats entirely (for example, a few older compilers had used a 32-bit version of the OMF format and its associated LIB format instead of COFF/AR). there are also differences in the contents of various header-files (ex: what exactly is a "FILE"?), there are differences in terms of parts of the C ABI, and often a very different C++ name mangling scheme and ABI (so C++ object-files are usually incompatible).
 
the end result is that while sometimes it is possible to force things to link between compilers, usually the result will either not work (at all or at least not correctly) and/or be prone to crashing.
 
 

2) do this incompatibility occur between across verisons of compilers 
or it only occurs between different compilers (I mean can lib not works if 
made with older version of compiller with the newer version of the same 
brand compiler or in one compiler it will work for all verions)

it can apply between compiler versions for the same compiler as well.

for example, both MSVC and GCC have changed their ABIs in various ways between compiler versions, so code linked between different compiler versions is prone to not work and/or result in crashes.

this is generally less of an issue for DLLs, as the basic C calling conventions (cdecl and stdcall) are pretty much frozen, and also both MSVC and GCC agree in most areas WRT the basic C ABI, and MS is adverse to changing things which will break existing software.

however, the C++ ABI is compiler specific, and there are a lot of minor edge cases where the C ABI differs between compilers (namely WRT passing/returning structs, the handling of types like "long double" and "__m128", ...), so some care is still needed.

it may also be observed that many/most Windows libraries tend to use a fairly constrained C subset for their APIs (and COM and similar are built on top of the C ABI).

 

3) are the gcc/vs/intel/what else partially compatible - or in general mostly not compatible
4) is there a way of mending a incompatible lib in some way ?
 
tnx for the answer (it seem to me tah it may be hard to answer thiss fully but at least partially - i would like to build some wiev on this static lib - hell  in windows, how the things look like)

when possible, build things from source all with the same version of the same compiler. Edited by BGB
2

Share this post


Link to post
Share on other sites

so it looks bad..

 

Is there any physical reason against the making lib (static libs format) (saying on one platform) working across all compilers and verisons?

 

Seem no.. (at least speaking about c, I am using c interface libraries only)

 

so this is bad, and this is guilt of compiler society - it should be standarized and this hell wouldnt be existing - every lib for win32 would be working with every compiler - i would call it normal situation 

 

[as to compiling libs from sources.. you seem to suggest everyone is doing that? I am not good at it.. Probably it brings its own bag of obstacles in the box , ?]

 

as to reasons (when speaking about c interface libs, I am only use) I understand the main source of incompatibility are just the symbol names (underscoress and so), Or there is something other above that?          I assume most compilers use coff libs today, old borland omf I incidentally know a bit because back then i was using b55 heavy by a couple of years, but (Im not sure) isnt it is conversable to coff with some tool (agner for as i vaguelly remember had such a tool 

on his page)

 

So as i said I do not see it clearly but It vaguelly seems to me that reasons of this incompatibility between static libs are not so much Heavy.. Is there something more than can be spoiled above just the linker symbol names? is someone here able to answer this?

-1

Share this post


Link to post
Share on other sites
In practice it isn't a big deal.

Even when you are using the same compiler, you can have the problems when you build it twice with incompatible options.

Build everything from the source yourself. If you have a system that you cannot build from source (which is often a bad idea) then do what you can to remain compatible while trying to get the source. Note that even the major compilers provide source code to their standard libraries so you can build them from source if you need.
2

Share this post


Link to post
Share on other sites


In practice it isn't a big deal.
Assuming you've got the source to everything cool.png

 

If you're using closed-source C++ libraries, you need to be sure that the vendor has compiled it using the exact same compiler (and compiler options) to what you need...

It would probably be better to just ask the vendor to give you a C version of their library instead laugh.png

2

Share this post


Link to post
Share on other sites

In practice it isn't a big deal.

Assuming you've got the source to everything :cool: 
In two decades, with teams as small as 5 people, I have not seen it as an actual problem. Maybe it is a problem for other people.

It is easily avoided, either by getting contracts that require source code or by using major reputable companies that provide builds in all shapes and sizes, and as part of the contract will provide them for you as needed.

Games have a fun feature that approximately zero major games use the standard memory allocation systems. External libraries that fail to use custom allocators for everything tend to cause no end of problems, so 3rd parties typically ship with source for that reason alone.


I only remember one time (in 21 years) not having either source or compatible builds was an issue, and it was a simple matter: We told our boss (the studio owner) that we could not use the product due to lack of source and to cancel the contract; we were going to cut the features that relied on the library. The following day their technology lead contacted our lead programmer directly begging for us to take them back (apparently they only had 2-3 total customers), and after passing it on to the company owner that we could use the product if we were allowed to view and potentially modify the source, we not only got the source but negotiated about half the cost as well.
0

Share this post


Link to post
Share on other sites

 


In practice it isn't a big deal.
Assuming you've got the source to everything cool.png

 

If you're using closed-source C++ libraries, you need to be sure that the vendor has compiled it using the exact same compiler (and compiler options) to what you need...

It would probably be better to just ask the vendor to give you a C version of their library instead laugh.png

 

well maybe i do not wrote it clearry but I was asking about c interface libs? you talking about c++?

 

As i said It seem to me that this c (c interface) libs are also incompatible (has incompatible interfaces?) but also I suspect that this incompatibility  is not major - isnt this just a metter of symbols?

specifically i wold be most curious what is a reason between incompatibility of c - like static libs made with VS against those of GCC/mingw

0

Share this post


Link to post
Share on other sites

 

 

In practice it isn't a big deal.

Assuming you've got the source to everything cool.png
In two decades, with teams as small as 5 people, I have not seen it as an actual problem. Maybe it is a problem for other people.
 

 

This big is relative ;/ I understand what you say , but still maybe it is not very big deal but still some deal ;\ Really static libs are done to work, as i said if they could work it is bad that they do not work ;\

 

Also it is really so easy to complie sources?, i am using mingw  (presently i dont even know how to use make) Is there easy to compile sources made with VS, they probably use different build systems or something.. I got not a practice in it

(also some sources (for quite interestin things) are made with some old compilers, i remember vaguelly i was trying to get some lib for c-interpreter (so I could use c scripts, it was fun idea, big advantages) wasnt it cint or something? but it was old and I get no skills to compile it, if this would be just lib (even old) i could use it, but old (and messy as big sources are always not redeable and undertstandable to me) sources 

seemed unusable to me

 

what with that ? ;/

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0