Golink error

[mitchi]

Hello,

I am trying to link my C SDL game using GoLink but it's not working.

Code Select Expand

\mario sokoban\Release>GoLink.exe /entry mainCRTStartup main.obj jeu.obj fichiers.obj editeur.o
bj

GoLink.Exe Version 0.26.9e - Copyright Jeremy Gordon 2002/9-JG@JGnet.co.uk

Error!
An object file was given to GoLink whose format was not supported (main.obj)
Output file not made

The compiler used was cl from Visual Studio 2008. I usually link with Microsoft linker using the GUI but I want to learn how to link with GoLink.
And one other thing : If I code an assembly function that I use with extern "c" in my program, is it better to link a .lib or a .obj ? I only got it to work using .lib

[jorgon]

Hi Mitchi

Would you mind either posting main.obj or sending it to me directly so I can have a look at it, thanks.

As for linking using a .lib, GoLink ignores lib files so if you are successfully linking using a .lib file and not an .obj file, maybe you could remove the name of the file altogether!

[mitchi]

Here :
http://mitchi.u7n.org/forGordon.zip

This is my release folder, with all the .obj and .DLL needed in it. If you need everything I have it in .7z on my server but it's bigger (1meg).

[jorgon]

Hi Mitchi

Thanks for posting the files.

I can see that the .obj files are created by the "C" compiler within Visual Studio.

Looking at them I can see that they are not in COFF format which is the format expected by GoLink. 

I believe the reason for this is that you have specified the /GL switch in the "C" compiler command line (this is the "whole program optimization" option switch on).  According to the Microsoft article at http://msdn.microsoft.com/en-us/library/0zza0de8.aspx, and this Intel article http://software.intel.com/en-us/articles/intel-c-compiler-compatibility-with-microsoft-visual-c/, object files produced using the /GL switch have a "proprietary intermediate representation".

So you could try switching off "whole program optimization" and see if that makes a difference.

[mitchi]

Thank you Gordon ! You were.. right on the mark.

Code Select Expand


GoLink.Exe Version 0.26.9e - Copyright Jeremy Gordon 2002/9-JG@JGnet.co.uk

Error!
The following symbols were not defined in the object file or files:-
_SDL_Quit
_SDL_FreeSurface
_SDL_Flip
_SDL_UpperBlit
_SDL_FillRect
_SDL_MapRGB
_SDL_WaitEvent
_SDL_WM_SetCaption
_SDL_SetVideoMode
_SDL_WM_SetIcon
_IMG_Load
_SDL_Init
_objectif
_caisseOK
_marioActuel
_carte
_mario
_lastDirection
_position
_positionJoueur
_caisse
_event
_mur
_SDL_EnableKeyRepeat
__imp__exit
_memset
__imp__fclose
__imp__fgets
__imp__fopen
__imp__fprintf
Output file not made


Now I have these errors, but I think I read something somewhere about this name mangling issue, I will probably solve this before anybody comes to help :P
I am converting this SDL game to GoASM. It's hard work but I can use the compiler output to help me and I learn at the same time =D. I've done 1/3 of the work already.

[mitchi]

First, I thank Vortex for this undecor tool, it worked well.

Ok, I need help after all  :(

Code Select Expand

C:\Users\chap\Documents\Visual Studio 2008\Projects\mario sokoban\mario sokoban\
Release>GoLink.exe main.obj jeu.obj editeur.obj fichiers.obj MSVCRT.dll SDL.dll
SDL_image.dll

GoLink.Exe Version 0.26.9e - Copyright Jeremy Gordon 2002/9-JG@JGnet.co.uk

Error!
The following symbols were not defined in the object file or files:-
objectif
caisseOK
marioActuel
carte
mario
lastDirection
position
positionJoueur
caisse
event
mur
Output file not made

These "things" are all global variables I use in my C program. What should I do ? They don't appear in the .h, just in the .c

Code Select Expand

//Carte dans le heap
int carte[NB_BLOCS_LARGEUR][NB_BLOCS_HAUTEUR];
SDL_Surface* mario[4]; // 4 surfaces pour chacune des directions de mario
SDL_Surface *mur,*caisse,*caisseOK,*objectif,*marioActuel;
SDL_Rect position, positionJoueur;
SDL_Event event;

[jorgon]

Mitchi

I'm sorry, but would you mind giving me the object files as they now are, and I shall look into this.

Thanks

[jorgon]

Mitchi

If you could kindly let me have the object files before amendment with Vortex's undecorate tool, I will see if I can add a switch to enable GoLink to resolve decorated symbols in object files created by the "C" compiler.  This is actually a different type of decoration which you see with other tools, but you are not the first person who has had problems with this so I do intend to try to sort this out.

[mitchi]

Here you go:
http://mitchi.u7n.org/gordon2.zip

[jorgon]

Thanks very much Mitchi.

I can now work on your files.

My aim is to permit GoLink to take a mix of MASM, "C", and GoAsm object files, and also to permit MASM and "C" static code libraries used in a GoAsm source file to call other static code libraries also used in GoAsm source, or in other modules.  In each case there is a symbol decoration issue (MASM and "C" object files will have decorated symbols as will code from non-GoAsm static code libraries).

I have a model which will resolve these issues, which does not need a command line switch, and which does not slow down GoLink much at all.  It relies on GoLink recognising GoAsm object files and therefore knowing that there is no automatic decoration in them (a GoAsm object file always has a unique symbol).  But I have to think through the problems which might arise if GoLink is also given object files from other assemblers or compilers which also do not decorate symbols.   These will not necessarily be identifiable.  The problem is as Vortex has said, that the leading underscore decoration may be there on purpose (a user might intend to have a symbol HELLO and also a different symbol _HELLO), instead of it being added automatically by the assembler/compiler.

I would need a way to identify whether particular object files are automatically decorated or not, but I doubt whether this will be possible.

I am working on this though, and may have to change my model to suit the realities of the situation.  I do not want to slow GoLink down for straightforward GoAsm users, so one option may be to add a switch.

[mitchi]

Then, if I were you I would add a way for the user to tell GoAsm that the following object files don't have decorated names. Or add it later per request. It's a rare case because GoAsm is the only tool that I know that does this.
:bg

[jorgon]

It's a rare case because GoAsm is the only tool that I know that does this.

Well, neither NASM or FASM object files are normally decorated.

I decided to add a /mix switch, and will come back to you very soon with this.

[jorgon]

Mitchi

I have now added the /mix switch to GoLink see http://www.masm32.com/board/index.php?topic=10770.0.

Would you mind trying this?  It will not be necessary now to use Vortex's undecorate tool (although of course many thanks to Vortex for providing this tool!).

Judging from your third post, you may still find these unresolved:-

Code Select Expand

__imp__exit
__imp__fclose
__imp__fgets
__imp__fopen
__imp__fprintf

However, these would most likely be in DLL (possibly a run-time library).  You need to give the name of the DLL to GoLink so that it can find these imported functions.

[mitchi]

It doesn't really work. The mix switch does remove the leading underscore but when I link the DLL, it doesn't find the function.

Code Select Expand


C:\Users\chap\Desktop\gordon2>GoLink.exe /mix main.obj fichiers.obj jeu.obj edit
eur.obj SDL.DLL MSVCRT.DLL SDL_image.dll

GoLink.Exe Version 0.26.10 beta- Copyright Jeremy Gordon 2002/9-JG@JGnet.co.uk

Error!
The following symbols were not defined in the object file or files:-
SDL_Quit
SDL_FreeSurface
SDL_Flip
SDL_UpperBlit
SDL_FillRect
SDL_MapRGB
SDL_WaitEvent
SDL_WM_SetCaption
SDL_SetVideoMode
SDL_WM_SetIcon
IMG_Load
SDL_Init
fclose
fgets
fopen
memset
fprintf
objectif
caisseOK
marioActuel
carte
mario
lastDirection
position
positionJoueur
caisse
event
mur
SDL_EnableKeyRepeat
Output file not made

C:\Users\chap\Desktop\gordon2>

[jorgon]

Ok Mitchi, thanks for the report.

I can see that your files call procedures in the DLLs which are not being found by GoLink.
This is because GoLink expects "__imp__" type decoration or at least "_CodeName@xx" decoration for such DLL calls if they are decorated at all.  Although I do not use "C", I believe at least the first type of decoration is a result of using the __declspec(dllimport) keyword.
The decoration in your DLL calls is merely of the type "_CodeName", and this may be because in the extrn declaration for these calls in your source code, you have merely used PROC.  This is fine with me as far as syntax is concerned, since I would not force you to use any more complicated syntax than is the very minimum required for the tools that you are using (this being the Go tools tradition).
However, before allowing GoLink to accept mere "_CodeName" decoration, I need to check back a little, because I recall a GoLink user having difficulty in resolving his DLL calls where he was intentionally using a leading underscore, and as a result I made GoLink a little more strict in this respect, so that it required "__imp__" type decoration or at least "_CodeName@xx" decoration.

I'll come back to you very soon.