[lsb-discuss] Missing symbols when using ifort for mixed C/Fortran

Craig Scott craig.scott at csiro.au
Sun Jan 9 02:34:02 PST 2011


Indeed, a missing libc_nonshared.a was the problem. Either way, I end up having to supply "hidden" libraries. Either I use ifort to link and have to add the normally-left-unspecified gcc/lsbcc libraries like libc_nonshared, or I use gcc/lsbcc and then have to add the normally-left-unspecified ifort libraries like libifport and libifcoremt. Since the particular case I'm dealing with is some third party code with its own custom build system, I think I'll just stick with the "principle of least stuffing around" on this one and add the libc_nonshared with the default ifort link. ;)

Thanks for the clues Rob and Mats.


On Sat, 8 Jan 2011 11:53:51 pm Wichmann, Mats D wrote:
> lsb-discuss-bounces at lists.linux-foundation.org wrote:
> > Ran into an interesting problem today. I have a 64-bit machine
> > (SLED 11) on which I'm building some mixed C/Fortran code
> > using the intel ifort compiler. This particular combination
> > builds fine with ifort/gcc on various platforms (32- and
> > 64-bit, various flavours of linux). However, if I build the C
> > parts with the lsbcc compiler instead, then when ifort goes to
> > link a program I see the following error:
> > 
> > /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crt1.o: In
> > function `_start':
> > /usr/src/packages/BUILD/glibc-2.9/csu/../sysdeps/x86_64/elf/sta 
> rt.S:106: undefined reference to `__libc_csu_fini'
> > /usr/src/packages/BUILD/glibc-2.9/csu/../sysdeps/x86_64/elf/sta
> rt.S:107: undefined reference to `__libc_csu_init'
> > 
> > 
> > The command that leads to this is:
> > 
> > /opt/intel/Compiler/11.1/064/bin/intel64/ifort -assume
> > old_logical_ldio -O3 -o someapp someapp.f -L`pwd` -lpgplot
> > -L/opt/lsb/lib64-4.0 -lX11 
> > 
> > Since this problem is specific to using the lsbcc compiler in
> > this context, I thought I'd ask if anyone here has any ideas
> > about what might be going on. The only references I can find
> > online to something vaguely like this talk about a missing
> > 32-bit glibc library, but I'm not yet convinced this applies
> > here (and if it did, I'm not sure how we could deal with it in a
> > LSB-friendly way). 
> > 
> > Let's not worry about whether the resulting binary would
> > actually be LSB-compatible just yet. Just getting it to build
> > is step 1, after which I can then check if any non-LSB symbols
> > exist in the resultant binaries.
> 
> you're not picking up libc_nonshared.a somehow, is what it
> looks like.
> 
> When you link a binary with gcc, it picks up libc.so which is
> actually not a library, but a linker script, and contains
> an instruction to use libc_nonshared.a.  Since in the LSB
> context, we don't use this file, lsbcc "knows" internally
> to add the instruction to include libc_nonshared.
> 
> We need to make sure that's happening when you use ifort.
> As Robert says, if it can be arranged, you're better off
> using lsbcc to do the final link, as it has the info to
> get this stuff right for itself.
> 
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss
> 

-- 
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia


More information about the lsb-discuss mailing list