Re: trying to build a DLL on Windows 7 gcc using 3rd party libraries

[Ray Holme <rayholme at yahoo dot com>]

I may have found the problem here, but I am in Microsoft land and am not sure of myself.

It would appear that the version of gcc that I installed is 32 bit - the name is MINGW32.

It would appear that the version of the firebird software is 64 bit so the libraries are 64 bit.

This is probably why the link does not deal well with the libraries.

In Unix I could be sure as I could say "file gcc.exe" ....

I will make sure that the two are compabible and try again.

Very confused - if anyone can tell me the MS equivalent of Unix/Linux "file", that would help a lot.

Ray



----- Original Message -----
From: Ángel González <keisial@gmail.com>
To: Ray Holme <rayholme@yahoo.com>
Cc: "gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
Sent: Sunday, April 29, 2012 10:33 AM
Subject: Re: trying to build a DLL on Windows 7 gcc using 3rd party libraries

On 29/04/12 14:59, Ray Holme wrote:
> NO, using dll's does not work - see below. Using lib files comes closest but the two routines that I am seeking to link to are not being found (I know they are there, one in each .lib).
>
> So I am not sure why some people are asking me about security. This is NOT an issue here. The only issue is linking (the ld stage of gcc). Security is addressed but it not part of what I am trying to do right now.
I agree.

> My last resort is to use the Visual Microsoft suite. I am sure that will work but what is the use of gcc on Microsoft if it fails building one of the most important tools needed - a dynamic link library.
> However the problem does NOT appear to be with my code declarations (maybe later when it is a .dll - then maybe it will matter). BUT FOR NOW, the problem is getting the functions in the two external libraries to be found (do they need a special prefix declarative too - they are in .h files from the provider now and that used to work with the Borland compiler). I could put in additional externs if that would help in local files (but then they would clash with the include files).
Calling convention *could* be influencing why you're not being able to
link, since they map to a mangling scheme (which is not always followed...).

> --- here is a try with the dll's (for the record and suggester's of same) 
>? 
> gcc -shared -o vetAdmin.dll udf.o fbclient.dll ib_util.dll -Wl,--export-all-symbols -Wl,--enable-auto-import 
>? 
> fbclient.dll: file not recognized: File format not recognized 
That's strange. I have used dlls as direct linking objects in the past
(maybe the difference is that you're making a dll).

> collect2: ld returned 1 exit status 
>? 
> --here is a try using the lib files 
>? 
> gcc -shared -o vetAdmin.dll udf.o fbclient_ms.lib ib_util_ms.lib -Wl,--export-all-symbols -Wl,--enable-auto-import 
>? 
> udf.o:udf.c:(.text+0x1ce): undefined reference to `isc_decode_date@8' 
> udf.o:udf.c:(.text+0x205): undefined reference to `ib_util_malloc' 
> collect2: ld returned 1 exit status
isc_decode_date seems to be using stdcall.

I wonder if ib_util_malloc is really ib_util_malloc or mangled _ib_util_malloc.

Have you looked at the exports of those libraries?
You could use pexports or dumpbin by Microsoft.


Are those libraries available somewhere so that we can test with them?

Regards