Lot of undefined symbols at link time, even with -l option on good libraries

[Frédéric ORMANCEY]

Thanks for this sample code => we are not far of the solution !

Same sample compile on my platform gives the following :
 V:>gnatmake imp
       gnatbind -x imp.ali
       gnatlink imp.ali
       ./imp.o(.text+0x20):imp.adb: undefined reference to `_FormatMessageA'
       collect2: ld returned 1 exit status
       gnatlink: cannot call /usr/bin/gcc.exe
       gnatmake: *** link failed.

And of course nm command as a different result also :
00000000 b .bss
00000000 d .data
00000000 t .text
                U _FormatMessageA
00000000 T __ada_imp

Problem is in compile time, not in build time, my compiler doesn't 
generate apropriate symbols in objects files !

I'am using cygwin 1.5.11-1 ( latest release ) with GNAT / GCC 3.4.1  ( 
gcc-ada-3.4.1-20040711-1.tar.gz package ).
I can't use older version of GNAT because of bugs in gnat.socket package 
( Gnat form of select() function limited to 32 simultaneous sockets for 
example ).



Cliff Hones a écrit :

>Larry Hall wrote:
>  
>
>>At 01:14 PM 9/22/2004, you wrote:
>>
>>    
>>
>>>>-----Original Message-----
>>>>From: Frédéric ORMANCEY
>>>>Sent: 22 September 2004 18:07
>>>>        
>>>>
>>>>I did it, but it don't work !
>>>>        
>>>>
>>>Ah, ok, that was not clear from your last message!
>>>
>>>
>>>      
>>>
>>>>The --enable-stdcall-fixup option suppress one warning on top 
>>>>of linker output trace :
>>>>   AVERTISSEMENT: résolution de _GetModuleHandleA par un 
>>>>lien vers _GetModuleHandleA@4
>>>>and unfortunatly leave ALL other errors with no effect on it.
>>>>        
>>>>
>>>I see.  Hmm.  That's very strange; it should affect all the errors - that
>>>is, if they're all the same kind of error.  OTOH it could be that you've
>>>gotten the calling conventions wrong with the other pragmas, so that's why
>>>--enable-stdcall-fixup doesn't work for them; there must be some different
>>>reason why the errors are caused, since they behave differently.
>>>
>>>You might care to experiment with the "--enable-auto-import" and, failing
>>>that, "--enable-extra-pe-debug" options as well.
>>>      
>>>
>>Or Frédéric could try specifying the link symbol he wants in the pragma
>>as suggested by an earlier poster (sorry, the thread is broken in the 
>>archives and I didn't put any effort into wading through the messages 
>>to trace it all back to that message).
>>    
>>
>
>That was me - but it seems Dave Korn's post broke the thread.  But isn't
>it easy enough to sort messages on subject?
>
>Anyway, I tried a noddy example, as follows...
>
>Cliff@enigma ~
>$ cat imp.adb
>procedure imp is
>  procedure Doit(A : integer; B : boolean; C : character);
>  pragma Import (Stdcall, Doit, "FormatMessageA");
>begin
>  Doit(1, true, 'x');
>end;
>
>Cliff@enigma ~
>$ gnat compile imp.adb
>gcc -c imp.adb
>
>Cliff@enigma ~
>$ nm imp.o
>00000000 b .bss
>00000000 d .data
>00000000 t .text
>         U _FormatMessageA@12
>00000000 T __ada_imp
>
>So Gnat is generating a stdcall-style linker symbol with @12 (the
>parameter block size) correctly appended.  If Frédéric is not seeing
>this with stdcall, it is probably an indication that the specification
>used for Doit is wrong - ie it hasn't been defined to take any parameters.
>
>If you change the pragma line to
>    pragma Import (Stdcall, Doit, Link_Name => "FormatMessageA");
>the symbol is generated as
>         U FormatMessageA@12
>
>so you can generate it without the leading underscore, but with the
>stdcall postfix, if you wish.
>
>[Note - the above is just an example - the *real* FormatMessageA should
>take 7 words (28 bytes) of parameters, and the Ada spec should match the
>kernel32 definition.]
>
>
>-- Cliff
>
>
>--
>Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>Problem reports:       http://cygwin.com/problems.html
>Documentation:         http://cygwin.com/docs.html
>FAQ:                   http://cygwin.com/faq/
>
>
>
>  
>

-- 

*_Frédéric  ORMANCEY_*

Atos Origin Systems Integration  

/rue Ampère - BP 475  
31315 Labège Cedex/

/Tel// /: 05 61 39 75 21
/Fax /: 05 61 39 16 65 
frederic.ormancey@atosorigin.com <mailto:frederic.ormancey@atosorigin.com>
www.si.fr.atosorigin.com


=======================================================================================================
Ce message électronique est confidentiel. Il peut contenir des 
informations protégées par le secret professionnel, le secret de 
fabrication ou autres règles légales. Si vous recevez ce message par 
erreur, il vous est interdit de le reproduire ou de le distribuer en 
tout ou partie, ou de le divulguer de quelque manière que ce soit à 
quelque personne que ce soit. Nous vous prions de bien vouloir en 
informer Atos Origin, par téléphone ou par retour d'e-mail puis de 
détruire le message et toutes copies de votre système informatique.
Le contenu de ce message ne reflète pas nécessairement ni les opinions 
d'Atos Origin ni celles des membres de son groupe. Bien que l'émetteur 
de ce message ait fait tout son possible pour maintenir son système 
informatique sans virus, il ne peut garantir que cette transmission ne 
comporte aucun virus et il ne pourra être tenu pour responsable de 
quelque dommage que ce soit résultant de la transmission d'un virus.
=======================================================================================================

 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/