Hi,

when I try to run a program that dynamically links an external .so library it throws a SIGSEGV seems to happen while loading the library before any code of mine is exeuted.

The library is pulled into it by a header translation from C to Pascal. The functions are declared "...; stdcall; external libname name xxx'. This way it worked on i386.

When the error occurs the ASM window pops up, which is not very helpful for me.

There may be a minor change in the lib source itself, but compiling the header and linking works OK. I have no idea how to check besides getting the older versions source and try again. Will try if nothing else is fishy.

My questions:

Is there any difference in declaring external functions between 32 and 64 bit mode?

How can I debug what is happening? Will compiling the library having an external debug file work when debugging from Lazarus?

Any hints for diagnosing what's going wrong are very welcome.

Some data points:
fpc 2.6.2 x86_64
library is compiled to 64 bit
FreeBSD 9.1-STABLE amd64

Best regards,
Marc

I did test the old library and the error is the same.

GDB tells me it happens when starting at BEGIN and running the init function of the library. That function does not have any arguments, I'm assuming "something else" then ...

Marc,

If your running on a *nix system then you probably want "cdecl" rather than "stdcall"

Regards

Tony Whyman
MWA

Marc,

If your running on a *nix system then you probably want "cdecl" rather than "stdcall"

Regards

Tony Whyman
MWA

Tony Whyman wrote

Marc, If your running on a *nix system then you probably want "cdecl" rather than "stdcall"

Err ... you're right and it is cdecl. I have mixed it up because it is an $if_n_def ...:

...;{$ifndef Win32}cdecl{$else}stdcall{$endif};external libname name 'xxx';

If I find the time I'll go on and investigate the exact position the error occurs. Maybe it is possible to build it with debugging symbols, in code I have to find a way throug the macro djungle ... one reason to use Object Pascal.

Thanks for waking me up. ;)

Marc

Marc Santhoff wrote

Some data points: fpc 2.6.2 x86_64

Always use the latest FPC release, in this case 2.6.4. I think even some x86-64 calling convention issues were fixed between 2.6.2 and 2.6.4.

Jonas

A pity, because that would have been an easy fix. This type of error comes from either mis-matched calling conventions or incompatible argument lists.

From having done this sort of thing before all I can advise is to go through each function argument one by one and make sure that each argument type is exactly the same in terms of data representation. When going between 32 and 64 bit you can often find that there are subtle differences in how the different compilers treat types resulting in a type that might be compatible in the 32 bit world, ceasing to be compatible in the 64bit world.

Also: you are using a 'C' library and not a C++ library aren't you?

Done, no change.

Thanks for pointing out.

Tony Whyman wrote

A pity, because that would have been an easy fix. This type of error comes from either mis-matched calling conventions or incompatible argument lists.

No easy solution in sight...

I already started checking type sizes, but looking at the code is very tough because of heavy use of macros.

Hopefully I can tweak those autoxxx-stuff into building a debug version of the library. That should help in getting to know what exactly happens where.

If that fails it'll be the time to polish some preprocessor tricks.

Also: you are using a 'C' library and not a C++ library aren't you?

Yes.

Thanks so far.

Wow, completely building a program (clean, compile, link) is a lot faster than on 2.6.2 running on FreeBSD 9. :)

Hi again,

OK, I've got it. Making a debug version of the library and using gdb showed me it was threading code that triggers the error.

Adding 'cthreads' to the uses clause resolved this error.

Puh,
Marc