Re: Linking GCC obgject files with Intel FORTRAN for linux

["W Bauske" <wsb at paralleldata dot com>]

Thank you. That fixed it. Everything linked and I'm running tests
now to make sure the binaries behave. 

I don't know why the beta compiler worked but it did. Perhaps
something changed in libintrins between the beta code and the
released code.

Wes Bauske


"Zhang, Yingwei" wrote:
> 
> Intel 5.0 Compiler relies on .gdt section for correct C++
> exception handling. libintrins is a Fortran library written
> in C++. Looks to me you are using gcc to link the library.
> I do not know why beta works unless you were using icc at the final
> link state. Even using gcc as link driver works, the C++ exception
> handling mechanism will not be functioning. I guess
> you do not care for this case since fortran does not throw
> exceptions, nor it knows how to handle exception if its library throws.
> 
> To fix the problem under gcc, you can either add the file icrt.link as
> one object and link it into your finial application (it will be treated
> as linker script), or define this symbol through either assembly file
> or linker command. However, I would suggest stick with icc as linker driver.
> 
> Intel 6.0 compiler is using a different object model for C++, and
> objects produced from icc and gcc should be able to mix and match
> (with some constrains, like same set of headers are used).
> 
> Yinwei Zhang
> Intel Compiler Lab
> 
> -----Original Message-----
> From: Narayanaswamy, Ravi
> Sent: Friday, September 28, 2001 5:11 PM
> To: Zhang, Yingwei
> Cc: Rao, Suresh K
> Subject: FW: Linking GCC obgject files with Intel FORTRAN for linux
> 
> Yingwei,
>    Is this your work or Milind's group.
> Ravi
> 
> -----Original Message-----
> From: W Bauske [mailto:wsb@paralleldata.com]
> Sent: Friday, September 28, 2001 5:09 PM
> To: binutils@sources.redhat.com
> Subject: Linking GCC obgject files with Intel FORTRAN for linux
> 
> Hello,
> 
> Hopefully someone can help me understand what I've done wrong.
> I have an application that uses C for the main program and calls
> FORTRAN subroutines to do the real work. I had been using the
> Intel FORTRAN Beta compiler without difficulty. Just had to add
> the Intel libraries to the link libs when I linked. Now that Intel
> have released the real compiler, the links fail with missing
> symbols.
> 
> /z/home/intel.compilers/ifc.pro/compiler50/ia32/lib/libintrins.so: undefined
> reference to
> `__gdt_lastone'
> /z/home/intel.compilers/ifc.pro/compiler50/ia32/lib/libintrins.so: undefined
> reference to
> `__gdt_firstone'
> collect2: ld returned 1 exit status
> 
> I found a file in the Intel directories called icrt.link:
> 
> /* static char cvs_id[] = "$Id: icrt.link,v 1.1 2001/02/16 09:16:06 grigory
> Exp $"; */
> /* for ICC C++ exception handling */
> SECTIONS
> {
>     .data1 :
>     {
>         *(.data1)                       /* Original .data1 section */
> 
>         PROVIDE(__gdt_firstone = .);    /* _GDT *__gdt_firstone */
> 
>         *(.gdt)
>         *(.gnu.linkonce.g.\$gdt\$*)
> 
>         PROVIDE(__gdt_lastone = .);     /* _GDT *__gdt_lastone */
> 
>         *(.edt)
>         *(.gnu.linkonce.e.\$edt\$*)
>     }
> }
> 
> This appears to me to be some sort of linker directives where they provide
> symbols for the front and back of the thing called a 'gdt'. If someone has
> an idea about what Intel did and how to translate it to ld type info, please
> let me know. Perhap a snippet of asm/directives could do the same thing?
> 
> Thanks,
> 
> Wes Bauske (please reply directly to me at wsb@paralleldata.com)