* Linking with GNAT on Windows @ 2009-11-24 16:26 Maciej Sobczak 2009-11-24 17:34 ` Dmitry A. Kazakov 0 siblings, 1 reply; 8+ messages in thread From: Maciej Sobczak @ 2009-11-24 16:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linking with GNAT on Windows 2009-11-24 16:26 Linking with GNAT on Windows Maciej Sobczak @ 2009-11-24 17:34 ` Dmitry A. Kazakov 2009-11-24 18:03 ` Pascal Obry 2009-11-25 8:43 ` Maciej Sobczak 0 siblings, 2 replies; 8+ messages in thread From: Dmitry A. Kazakov @ 2009-11-24 17:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linking with GNAT on Windows 2009-11-24 17:34 ` Dmitry A. Kazakov @ 2009-11-24 18:03 ` Pascal Obry 2009-11-25 1:36 ` Kevin K 2009-11-25 8:43 ` Maciej Sobczak 1 sibling, 1 reply; 8+ messages in thread From: Pascal Obry @ 2009-11-24 18:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linking with GNAT on Windows 2009-11-24 18:03 ` Pascal Obry @ 2009-11-25 1:36 ` Kevin K 0 siblings, 0 replies; 8+ messages in thread From: Kevin K @ 2009-11-25 1:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linking with GNAT on Windows 2009-11-24 17:34 ` Dmitry A. Kazakov 2009-11-24 18:03 ` Pascal Obry @ 2009-11-25 8:43 ` Maciej Sobczak 2009-11-25 9:46 ` Dmitry A. Kazakov 1 sibling, 1 reply; 8+ messages in thread From: Maciej Sobczak @ 2009-11-25 8:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linking with GNAT on Windows 2009-11-25 8:43 ` Maciej Sobczak @ 2009-11-25 9:46 ` Dmitry A. Kazakov 2009-11-25 12:47 ` Maciej Sobczak 0 siblings, 1 reply; 8+ messages in thread From: Dmitry A. Kazakov @ 2009-11-25 9:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linking with GNAT on Windows 2009-11-25 9:46 ` Dmitry A. Kazakov @ 2009-11-25 12:47 ` Maciej Sobczak 2009-11-25 13:44 ` Dmitry A. Kazakov 0 siblings, 1 reply; 8+ messages in thread From: Maciej Sobczak @ 2009-11-25 12:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linking with GNAT on Windows 2009-11-25 12:47 ` Maciej Sobczak @ 2009-11-25 13:44 ` Dmitry A. Kazakov 0 siblings, 0 replies; 8+ messages in thread From: Dmitry A. Kazakov @ 2009-11-25 13:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-11-25 13:44 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-11-24 16:26 Linking with GNAT on Windows Maciej Sobczak 2009-11-24 17:34 ` Dmitry A. Kazakov 2009-11-24 18:03 ` Pascal Obry 2009-11-25 1:36 ` Kevin K 2009-11-25 8:43 ` Maciej Sobczak 2009-11-25 9:46 ` Dmitry A. Kazakov 2009-11-25 12:47 ` Maciej Sobczak 2009-11-25 13:44 ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox