Linking with GNAT on Windows

Linking with GNAT on Windows

[Maciej Sobczak]

Hi,

Imagine a C library compiled with Visual Studio. This library is used
by an Ada program by means of pragma Import.

When the C library is compiled in the Debug mode, GNAT can link the
whole program. If the same C library is compiled in the Release mode,
the GNAT linker says "undefined reference" with regard to the C
function that is imported by Ada.

I am pretty sure that people who are regularly targetting the Windows
platform have seen that already and could possibly help with a hint
(compiler/linker option on the Visual Studio side?) on how to proceed.
All suggestions are welcome.

This is GNAT 2009 and Visual Studio 2008.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Linking with GNAT on Windows

[Dmitry A. Kazakov]

On Tue, 24 Nov 2009 08:26:00 -0800 (PST), Maciej Sobczak wrote:

> Imagine a C library compiled with Visual Studio. This library is used
> by an Ada program by means of pragma Import.
> 
> When the C library is compiled in the Debug mode, GNAT can link the
> whole program. If the same C library is compiled in the Release mode,
> the GNAT linker says "undefined reference" with regard to the C
> function that is imported by Ada.

Hmm, it is no matter how the program is compiled, but how is it linked.
Debug/Release are just project scenario names, which can mean anything in
the concrete project.

Of course we cannot exclude that some inspired C programmer could make use
of #ifdef __DEBUG__ to change names of all functions in the source...

AFAIK, GNAT does not recognize the MS lib files, so you have to convert
them into *.a with the corresponding mangling of names especially if that
is C++ and not export "C" stuff.

There is also exist *.def files which may influence the names of the
entries in the import library.

Further there exist __declspec(dllexport), __cdecl, __stdcall modifiers in
the program, which might have effect on the external names.

Plus in Visual Studio there can be defined post build steps. which might
call scripts and do, well, anything.

All in one, it is impossible to say what is going on. You have to verify
all steps. I would ensure that *.a file is created and used by GNAT. Then I
would check the names in it (nm -s). Then I would verify the content of its
source *.lib file etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Linking with GNAT on Windows

[Pascal Obry]

Le 24/11/2009 18:34, Dmitry A. Kazakov a �crit :
> All in one, it is impossible to say what is going on. You have to verify
> all steps.

And check what the GNAT User's Guide has to say about all this.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Linking with GNAT on Windows

[Kevin K]

What I ended up doing when I needed to link some C code compiled under
Visual C++ into an Ada main (due to the code using APIs that weren't
supported under the SDK in GNAT environment) was to build a DLL with
the appropriate declaration.  The downside is that you can't debug it
that way.  When debugging is necessary, I need to create a driver in C
within Visual C++ and debug it there.

Re: Linking with GNAT on Windows

[Maciej Sobczak]

On 24 Lis, 18:34, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> Hmm, it is no matter how the program is compiled, but how is it linked.

The GNAT invocation is the same in both cases and includes this:

-largs -lmylibrary

with mylibrary.lib (the result of compilation on Visual Studio) file
somewhere around.

> Of course we cannot exclude that some inspired C programmer

I was that programmer. The whole C library amounts to a single
function with single line of code ("Hello from C", essentially), no
preprocessor and no other tricks. The function is declared as extern
"C" to avoid name mangling.

> AFAIK, GNAT does not recognize the MS lib files,

It seems to recognize them. Not only it complains when the file is not
around (note: it can automatically make an association between -
lmylibrary linker option and the mylibrary.lib file - this would not
be the case if .lib files were not supported at all), but it really
works fine if the C library is build in the Debug mode.
I have tried to analyze all options in these two modes, but do not see
any differences that would affect this.

> There is also exist *.def files which may influence the names of the
> entries in the import library.

Yes, but this is not used. My naive first diagnostics was that the
library compiled in Debug mode has its names exported by default,
whereas the Release mode would need the .def file. This theory is
contradicted by the fact that a test C program can use that library no
matter how it was compiled. But then, it is the single toolchain on
the whole path.

> Further there exist __declspec(dllexport), __cdecl, __stdcall modifiers in
> the program, which might have effect on the external names.

None of these are used. Note that it is a static library, not a DLL.

> Plus in Visual Studio there can be defined post build steps.

These are not defined. The C library was created as a pristine
project.

> All in one, it is impossible to say what is going on.

Cool.
I am pretty convinced that this is not even a GNAT issue, but rather
concerns the interaction of Visual Studio and MinGW toolchain that is
a backend for GNAT.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Linking with GNAT on Windows

[Dmitry A. Kazakov]

On Wed, 25 Nov 2009 00:43:11 -0800 (PST), Maciej Sobczak wrote:

> On 24 Lis, 18:34, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> Hmm, it is no matter how the program is compiled, but how is it linked.
> 
> The GNAT invocation is the same in both cases and includes this:
> 
> -largs -lmylibrary

Usually debug/release versions have different names like mylibraryd.lib or
else placed into different subdirectory like .\Debug vs. .\Release. What
about the "-L" switch?
 
> with mylibrary.lib (the result of compilation on Visual Studio) file
> somewhere around.
> 
>> Of course we cannot exclude that some inspired C programmer
> 
> I was that programmer. The whole C library amounts to a single
> function with single line of code ("Hello from C", essentially), no
> preprocessor and no other tricks. The function is declared as extern
> "C" to avoid name mangling.

OK, extern "C" normally mangles, e.g. adds underscore in front of the name.
Also, if I correctly remember, stdcall convention adds some funny suffixes
like "@4" to the names in import libraries. But that behavior is
independent on debug/release.

I think you should:

1. Remove all instances of mylibrary.lib.
2. Build it anew.
3. Ensure that GNAT links the library you have built.
4. If error persists, view the lib file. Compare names there and the
unresolved references reported by GNAT.

(There exist plug-ins for Window commander to list the entry points of a
library.)

>> AFAIK, GNAT does not recognize the MS lib files,
> 
> It seems to recognize them.

Yes, you are right. I forgot that.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Linking with GNAT on Windows

[Maciej Sobczak]

On 25 Lis, 10:46, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> Usually debug/release versions have different names like mylibraryd.lib or
> else placed into different subdirectory like .\Debug vs. .\Release. What
> about the "-L" switch?

If the file was not found, the linker would say so. Every -lmylibrary
option must have a corresponding library file.

> I think you should:
>
> 1. Remove all instances of mylibrary.lib.
> 2. Build it anew.
> 3. Ensure that GNAT links the library you have built.
> 4. If error persists, view the lib file. Compare names there and the
> unresolved references reported by GNAT.

Well, no. :-)
As already said, this is the interaction between Visual Studio and
MinGW, so can be completely reproduced outside of GNAT.

The problem proved to be related to the Visual optimization option
that is used to enable so-called whole-program optimization (Enable
link-time code generation). On command-line this is /GL option.

This option must be switched off. I hope this observation will help
other programmers.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Linking with GNAT on Windows

[Dmitry A. Kazakov]

On Wed, 25 Nov 2009 04:47:24 -0800 (PST), Maciej Sobczak wrote:

> The problem proved to be related to the Visual optimization option
> that is used to enable so-called whole-program optimization (Enable
> link-time code generation). On command-line this is /GL option.
>
> This option must be switched off. I hope this observation will help
> other programmers.

MSDN:

".obj files produced with /GL and precompiled header files should not be
used to build a .lib file unless the .lib file will be linked on the same
machine that produced the /GL .obj file. Information from the .obj file's
precompiled header file will be needed at link time."

That explains a lot. Noteworthy is mentioning precompiled headers. That
stuff never ever worked in VC... Presumably /GL silently killed the entry
point in the .lib file.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de