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

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

[Ray Holme]

I used to do this using Borland C but no longer have that machine. I have been told that the free Microsoft compiler will work, but I am aUnix/Linux person and would prefer to use gcc on the Windows machine(s) for compilation. Compiling the user-defined-function source works fine (I have appropriate __cdecl defined for the functions just as needed in Borland's compiler without __export). However linking the DLL is not so good - the problem appears to be in using the firebird libraries. I have both the library and dll versions of both in my current working directory (for now - till I get it working, then I will try using the "-L" option ....). From what I can see in the error listed below, gcc does NOT like these .lib libraries (I also tried the .dll files, but they really were not liked by the compiler).

Below is the command as entered on the PC and the error that follows.
E:\ray\vetadmin\UDF>gcc -shared -o vetAdmin.dll udf.o -Wl,--out-implib=libvetAdmin.dll.a ^
 -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--whole-archive fbclient_ms.lib ib_util_ms.lib

fbclient_ms.lib: member fbclient_ms.lib(fbclient.dll) in archive is not an object
collect2: ld returned 1 exit status

I also know that before the final compile and build with Borland I had to use the "implib" command (NO idea why) and it is not part of the gcc version (I think).

Does anyone know how to link using someone elses .lib files (C++ based)??

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

[Jeffrey Walton]

On Fri, Apr 27, 2012 at 5:14 PM, Ray Holme <rayholme@yahoo.com> wrote:
> I used to do this using Borland C but no longer have that machine. I have been told that the free Microsoft compiler will work, but I am aUnix/Linux person and would prefer to use gcc on the Windows machine(s) for compilation. Compiling the user-defined-function source works fine (I have appropriate __cdecl defined for the functions just as needed in Borland's compiler without __export). However linking the DLL is not so good - the problem appears to be in using the firebird libraries. I have both the library and dll versions of both in my current working directory (for now - till I get it working, then I will try using the "-L" option ....). From what I can see in the error listed below, gcc does NOT like these .lib libraries (I also tried the .dll files, but they really were not liked by the compiler).
>
> Below is the command as entered on the PC and the error that follows.
> E:\ray\vetadmin\UDF>gcc -shared -o vetAdmin.dll udf.o -Wl,--out-implib=libvetAdmin.dll.a ^
>  -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--whole-archive fbclient_ms.lib ib_util_ms.lib
I'm not sure how to dial it in using GCC, but you will also want to
use /GS, /SafeSEH, and /NXCOMPAT. If the source file is high risk
(such as parsing input from untrusted sources such as the internet),
you will want to add #pragma strict_gs_check(on) to the source file.

To be clear, these are Visual Studio switches to help with hardening.
But I don't now how to instruct the GNU tools to use, for example,
/SafeSEH. And I have not been able to find GCC reading on the
switches.

Jeff
.

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

[Ray Holme]

Just for the record, the command line switches are the latest I have tried and I have tried the simple ones.

There is an article on the net that I got this set from (without understanding what they are supposed to do). Here is the reference:


     http://www.cygwin.com/cygwin-ug-net/dll.html

I have no reason to build a .a file that this command seems to imply. Using the simple version:

  gcc -shared -o vetAdmin.dll udf.o fbclient_ms.lib ....

gives me errors about not finding the two routines I am trying to get from the .lib files

The fancier command listed first does not complain about NOT finding the routines, it just complains that the .lib files are not any good.
i am 99.999% sure that the libraries are fine.

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

[Ángel González]

On 28/04/12 21:58, Ray Holme wrote:
> Just for the record, the command line switches are the latest I have tried and I have tried the simple ones.
>
> There is an article on the net that I got this set from (without understanding what they are supposed to do). Here is the reference:
>
>
>      http://www.cygwin.com/cygwin-ug-net/dll.html
>
> I have no reason to build a .a file that this command seems to imply. Using the simple version:
>
>   gcc -shared -o vetAdmin.dll udf.o fbclient_ms.lib ....
>
> gives me errors about not finding the two routines I am trying to get from the .lib files
>
> The fancier command listed first does not complain about NOT finding the routines, it just complains that the .lib files are not any good.
> i am 99.999% sure that the libraries are fine.
Is fbclient_ms.lib a static library or an import lib for a
fbclient_ms.dll file?
I'd simply list fbclient_ms.dll in the command line as input file.

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

[Jeffrey Walton]

On Sat, Apr 28, 2012 at 3:58 PM, Ray Holme <rayholme@yahoo.com> wrote:
> Just for the record, the command line switches are the latest I have tried and I have tried the simple ones.
>
> There is an article on the net that I got this set from (without understanding what they are supposed to do). Here is the reference:
>
>
>      http://www.cygwin.com/cygwin-ug-net/dll.html
OK, thanks. It looks like its the minimum steps required to build a Windows DLL.

Its unfortunate the project do not address Windows platform security.
I would encourage you to use Visual Studio. Its the right tool for the
job on the Windows platform.

Jeff

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

[Ray Holme]

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. 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.

I have compiled all of my functions with a prototype such as

EXPORT(char *) func..

Where in Li/Unix the EXPORT function is nothing so the declaration becomes:
    char * func..
 and I have tried a few variants on the PC - gnu's gcc I tried:
    char * __cdecl func..
       and also tried (after perusing the stdlib.h file)
    _CRTIMP char * __cdecl __MINGW_NOTHROW func..
 (and for the record, Borland's C used to work with)
    char * __export __CDECL func..

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).

--- 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 
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

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

[Ángel González]

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

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

[Ray Holme]

[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]



>> 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).
>> ,,,

>isc_decode_date seems to be using stdcall.

  tried both stdcall and cdecl - both fail.

>I wonder if ib_util_malloc is really ib_util_malloc or mangled _ib_util_malloc

  that is possible and I could try that

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

  thanks, I will try those a little later today

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

The libraries and include files defining the failing routines are part of the FREE Firebird 2.5 distribution.

I have built a minimal version of my code which calls the two routines needed in the libraries, included a builddll.bat file which is how I TRY to build this; included the two firebird include files AND the two firebird libaries they point at. They are all attached for your viewing.

I will continue trying the two microsoft programs you suggested (if I have them, or try to download).

If you have these tools and can easily see some trivial changes to the "EXPORT" pre-compiler macro that I use, I would be eternally grateful.

[-- Attachment #2: for_angel.tar.gz --]
[-- Type: application/x-gzip, Size: 55222 bytes --]

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

[Ray Holme]

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

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

[Kai Ruottu]

3.5.2012 19:35, Ray Holme kirjoitti:

> 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.

Using 'objdump' with different options could be what you want.
For instance :

C:\opt\cross\i586-mingw32\wbin>dir
  Asemalla C ei ole nimeä.
  Aseman sarjanumero on 58E2-9BC5

  Kansio C:\opt\cross\i586-mingw32\wbin

29.02.2012  11:23       <KANSIO>       .
29.02.2012  11:23       <KANSIO>       ..
21.10.2011  23:25               56 334 iconv.exe
21.10.2011  23:25               30 734 libcharset-1.dll
26.02.2012  01:34              439 638 libgcc_s_dw2-1.dll
21.10.2011  23:25            1 038 350 libiconv-2.dll
24.08.2011  02:59               47 972 mingwm10.dll
                5 tiedosto(a)      1 613 028 tavua
                2 kansio(ta)  35 002 814 464 tavua vapaana

C:\opt\cross\i586-mingw32\wbin>objdump -f iconv.exe

iconv.exe:     file format pei-i386
architecture: i386, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x0040126c


C:\opt\cross\i586-mingw32\wbin>objdump -f libgcc_s_dw2-1.dll

libgcc_s_dw2-1.dll:     file format pei-i386
architecture: i386, flags 0x0000013b:
HAS_RELOC, EXEC_P, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, D_PAGED
start address 0x6e941058

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

[Kai Ruottu]

3.5.2012 19:35, Ray Holme kirjoitti:

> 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.

If the "firebird" means the following :

http://www.firebirdsql.org/en/firebird-2-5-1/

then there shouldn't be any mistake about what one has
downloaded and what not...

I downloaded both the 32-bit and 64-bit ZIP-packages and
looked if my 'i586-mingw32' target binutils could handle
these files. The result was :

- the 32-bit 'fbclient_ms.lib' could be viewed nicely with
   'nm', 'objdump' etc.

- the 64-bit 'fbclient_ms.lib' could not be viewed with
   'nm', 'objdump' etc.

Seemingly my GNU binutils for MinGW host/target were too old :

C:\opt\firebird64\lib>\opt\cross\i586-mingw32\bin\objdump --version
GNU objdump (Linux/GNU Binutils) 2.17.50.0.16.20070511

Generally I'm not aware of the 64-bit MinGW situation,
using the 32-bit 'Firebird-2.5.1.26351-0_Win32.zip' or
some earlier version could work with the 32-bit MinGW
tools, I think...

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

[Ray Holme]

Got it and thanks. Downloading the 32 bit version when the server comes back up. Will notify all of the results. Hoping for sucess.



----- Original Message -----
From: Kai Ruottu <kai.ruottu@wippies.com>
To: gcc-help@gcc.gnu.org
Cc: 
Sent: Thursday, May 3, 2012 2:33 PM
Subject: Re: trying to build a DLL on Windows 7 gcc using 3rd party libraries

3.5.2012 19:35, Ray Holme kirjoitti:

> 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.

If the "firebird" means the following :

http://www.firebirdsql.org/en/firebird-2-5-1/

then there shouldn't be any mistake about what one has
downloaded and what not...

I downloaded both the 32-bit and 64-bit ZIP-packages and
looked if my 'i586-mingw32' target binutils could handle
these files. The result was :

- the 32-bit 'fbclient_ms.lib' could be viewed nicely with
  'nm', 'objdump' etc.

- the 64-bit 'fbclient_ms.lib' could not be viewed with
  'nm', 'objdump' etc.

Seemingly my GNU binutils for MinGW host/target were too old :

C:\opt\firebird64\lib>\opt\cross\i586-mingw32\bin\objdump --version
GNU objdump (Linux/GNU Binutils) 2.17.50.0.16.20070511

Generally I'm not aware of the 64-bit MinGW situation,
using the 32-bit 'Firebird-2.5.1.26351-0_Win32.zip' or
some earlier version could work with the 32-bit MinGW
tools, I think...

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

[Ray Holme]

for the record - with the 32 bit libraries and "__cdec" defined for al functions, all works fine.



----- Original Message -----
From: Ray Holme <rayholme@yahoo.com>
To: Kai Ruottu <kai.ruottu@wippies.com>; "gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
Cc: 
Sent: Thursday, May 3, 2012 2:43 PM
Subject: Re: trying to build a DLL on Windows 7 gcc using 3rd party libraries

Got it and thanks. Downloading the 32 bit version when the server comes back up. Will notify all of the results. Hoping for sucess.



----- Original Message -----
From: Kai Ruottu <kai.ruottu@wippies.com>
To: gcc-help@gcc.gnu.org
Cc: 
Sent: Thursday, May 3, 2012 2:33 PM
Subject: Re: trying to build a DLL on Windows 7 gcc using 3rd party libraries

3.5.2012 19:35, Ray Holme kirjoitti:

> 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.

If the "firebird" means the following :

http://www.firebirdsql.org/en/firebird-2-5-1/

then there shouldn't be any mistake about what one has
downloaded and what not...

I downloaded both the 32-bit and 64-bit ZIP-packages and
looked if my 'i586-mingw32' target binutils could handle
these files. The result was :

- the 32-bit 'fbclient_ms.lib' could be viewed nicely with
  'nm', 'objdump' etc.

- the 64-bit 'fbclient_ms.lib' could not be viewed with
  'nm', 'objdump' etc.

Seemingly my GNU binutils for MinGW host/target were too old :

C:\opt\firebird64\lib>\opt\cross\i586-mingw32\bin\objdump --version
GNU objdump (Linux/GNU Binutils) 2.17.50.0.16.20070511

Generally I'm not aware of the 64-bit MinGW situation,
using the 32-bit 'Firebird-2.5.1.26351-0_Win32.zip' or
some earlier version could work with the 32-bit MinGW
tools, I think...

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

[Ángel González]

Sorry, I had missed this.

On 02/05/12 21:01, Ray Holme wrote:
> Angel,
>
> I could not find pexports (except on the net) but I did find dumpbin. I ran it against the two libraries like
>    dumpbin/EXPORTS fbclient_ms.lib ....
>
> It printed out a list of routines that are in the library, but NO information about how they are declared.
> The originator's own include files imply to use "__stdcall", but I am at a loss here as I am out of my element (Unix and therefore "ar").
No, it doesn't provide the call convention. I just expected the output
of the function name, if it had some prefixes or suffixes (they may be
added to give hints about the call convention).


On 03/05/12 18:35, Ray Holme wrote:
> 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
One way would be to copy the files to a Unix machine and run file there.
Another would be to get a version of file compiled for windows, such as
http://gnuwin32.sourceforge.net/packages/file.htm