Hello,

I'm trying to link my program statically with bzip2 library under Win32. The exported functions are declared as stdcall. I can link dynamically by declaring functions like this:

function BZ2_bzCompressInit(...): Integer; stdcall; external 'bz2';

It seems that whenever I explicitly give the library name after 'external' FPC always links dynamically, so if I want to link statically I do:

{$LINKLIB bz2}
function BZ2_bzCompressInit(...): Integer; stdcall; external;

But the names are mangled FPC style:

# nm abbzip2.o | grep -i bzCompressInit
U ABBZIP2_BZ2_BZCOMPRESSINIT$TBZSTREAMREC$LONGINT$LONGINT$LONGINT$$LONGINT

I found I can do this by specifying names of the functions, but I have to use mangled names:

{$LINKLIB bz2}
function BZ2_bzCompressInit(...): Integer; stdcall; external name
'';

Is there a way I can declare the external function to use "C" style mangling?

cobines wrote

Is there a way I can declare the external function to use "C" style mangling?

That's currently only possible if the function also uses the C calling convention.

Jonas

In our previous episode, cobines said:

That's (VB like) decoration, not C mangling. Only VS compilers use it. Afaik Delphi supports it neither.

2010/3/5 Jonas Maebe :

Ah, I see. Thanks.

2010/3/5 Marco van de Voort :

You're right, apparently it has nothing to do with C.

I am using MinGW GCC and it also adds this decoration.

Someone did this with Borland C++ 5 and Delphi (don't know which version), but Borland does not use this decoration and Delphi imports the functions by using plain undecorated names. I'll see, maybe there's a way to disable it in GCC.

cobines wrote

You're right, apparently it has nothing to do with C.

According to this, it has:

http://en.wikipedia.org/wiki/Name_mangling#C_name_decoration_in_Microsoft_Windows

You can pass --kill-at as an option to ld when you link the library (or gcc -Wl,--kill-at).

Henry

In our previous episode, Henry Vermaak said:

But the system libraries using stdcall do not use it, so apparantly it is turned off there. It makes more sense to make stdcall adhere to the system calling convention than the MSVC mangled version one. (that'd be a new modifier)

Henry Vermaak wrote

You can pass --kill-at as an option to ld when you link the library (or gcc -Wl,--kill-at).

You can even use --enable-stdcall-fixup when you you link your pascal program with ld. That should try and do what the docs call "fuzzy linking".

See: http://sourceware.org/binutils/docs/ld/Options.html#Options

Henry

It's a bit useless if you can't link to any other libraries, no? I guess you can still use ld instead of the internal llinker (and even import libs).

Henry

2010/3/5 Henry Vermaak :

I know and I use --kill-at when I build the dll, but I don't actually link the library if I want static linking. I put the library's object files into an archive (ar r libbz2.a *.o) and I link the pascal program with this archive (add {$LINKLIB bz2}). Or is it wrong method of linking statically?

In the object files the names are decorated ()
and that's how I have to specify them. I wanted to avoid specifying this decoration because on Win64 it is not applied (I don't know if only by GCC or other compilers too) and thought maybe FPC would do this for me. But I guess I can use {$IFDEF}'s and just put different names on Win32 and Win64.

In our previous episode, Henry Vermaak said:

You can, you just have to specify the decoration. Or if there is a large scale need a modifier or directive to modify stdcall to include decoration could be made by interested parties.

I guess you can still use ld instead of the internal llinker (and even import libs).

I'd just add the decoration manually. It is typically a one-off effort.

Maybe a command line param that does a more fuzzy linking?

> I guess you can still use ld instead of the internal llinker (and even > import libs). I'd just add the decoration manually. It is typically a one-off effort.

Except if you have cross platform code, then you need an ifdef for every function you import :(

Henry

In our previous episode, Henry Vermaak said:

It's still a one off. Annoying for hundreds of calls, but not really a problem for a few tens. It will be more work to craete a patch to fix this :-)

Is this a big task? I've never looked at the code for the linker.

In our previous episode, Henry Vermaak said:

I'm no inner-compiler developer, but it probably depends on what you want to do. Just fuzzy linking trying to match undecorated functions with decorated ones, or really evaluate the number of arguments to create the decoration on the "header" side, and then do exact linking.

The fuzzy option is easier, but the other stuff is probably also needed for generating libs with compatible decoration, as well as making use of the main use of decoration: overloading external symbols on the basis of number of parameters. (default param alike probably)