Jump to content
  • Advertisement
Sign in to follow this  

c++ libs linking tutorial? And I'm new here!

This topic is 1163 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

Hey all,


I'm new to this forum, so:


My background, in the past i've been a flash as3 programmer making games in the browser.

I have a game that is going quite well, but I felt this one deserved to be a c++ game.

So porting has begin! (flash was using Box2D, Starling, PureMVC, and some other libs)



I'm not BRAND new to c++, I've dabbled in it, but I do see that I need a much better grasp on how static vs dynamic libraries work. I'm already using and compiling successfully:


SDL2, SDL_mixer, SDL_image, SDL_ttf, Box2D

on linux and os x (xcode)
I'm having big issues trying to link the libs on windows for some reason


linux with code::blocks is my MAIN dev environment.



I'm not looking for "here's how you link it in windows", but more of a bigger picture: how does this linking work with compiler/linker stages. I've tried googling around, but maybe I just don't words to search that will bring me to the full clear answers.




I still have more libs to plug in, and want to make sure my 1 codebase can compile on windows, linux, and os x


So if anyone can share information, or links / tutorials to HOW this linker process works I'd greatly appreciate it.


(windows has compiled before, but i feel i did it in a messy way... so going back to basics to make sure i understand this before porting anything)



Share this post

Link to post
Share on other sites

What searches have you tried?


Keep in mind the binary runtime process is completely different on Windows comapred with Linux and Mac OS (which, themselves are different but also very similar).  Linking, in particular, works differently at the lower levels at both build and run time, so the which files are necessary is going to be different.


A summary of how it all works on any platform, in a vague and general way is as follows.


(1) The compiler translates a single text source file (header files and source files are combined by a preprocessor into a single translation unit) into an intermediate binary "object file" with an extension .OBJ on Windows and traditionally the last two character of the file name are .o on Unix-derived systems.  These object files contain a table of unresolved external references.


(2) The linker will take one or more object files and combine them into a dynamic shared object (DSO) such as a shared library or executable program.  At this time, all object files plus additional shared libraries need to be available to the linker so it can resolve those unresolved external references.


On all platforms, the only real difference between a "shared object" (.so file, .DLL file) and an executable (on WIndows, a file with a .EXE extension, on other platforms a file with appropriate magic in the first 4 bytes and the executable bit set in the filesystem) is a couple of flags in the binary header and the entry point published (again in the header).


On all systems the linker reads the object files and copies their contents into the DSO, building a table of unresolved references as it goes and resolving references where it can.  On Linux (ELF) and Mac OS (MACH-O) systems, the linker reads the .so files  to resolve many of the still-unresolved references, recording the SONAME (a special label identifying the DSO) of the .so as it does so.  Windows (COFF) systems do something similar, except it usually uses a .LIB files, a specially-build object file, to embed trampoline functions into the executable instead of using a jump table.


A program launch time, another program called the link loader (on ELF systems, it's called 'the interpreter', on Windows it's actually built into the OS) reads the external reference table of the DSO and opens and loads the appropriate .so/.DLL files, updating the jump tables as required.


Really, all the linker does is create a special table of information so that multiple files can be used together at runtime as one single self-contained executable image in memory while being built at different times in different places from multiple source files.

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!