Date: Thu, 24 Jan 2002 22:36:26 +0100 (CET) From: Alexander Leidinger <Alexander@Leidinger.net> To: dnelson@allantgroup.com Cc: rsidd@online.fr, ports@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Port: Intel Fortran (and C++?) compilers Message-ID: <200201242136.g0OLaRd01258@Magelan.Leidinger.net> In-Reply-To: <20020124192136.GG87583@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24 Jan, Dan Nelson wrote:
> In the last episode (Jan 24), Rahul Siddharthan said:
>> I have the Intel Fortran compiler[1] for Linux (Red Hat 7.1) working
>> on my FreeBSD box, and (barring as-yet-unseen glitches) would like to
>> submit a port by the weekend or so. I'd like some advice on how to
>> proceed with the following issues.
>
> I actually did the same thing you did, but with the C compiler :) I
> never write a port though.
But I have a port. :-)
>> 1. The compiler and its libraries are installed in
>> /compat/linux/opt/intel/compiler50/ia32/bin/ifc
>> and requires some environment variables pointing to a license file to
>> be set before it runs. I do that with a script called "ifc" in
>> /usr/local/bin, which does the right things. Is there a better way?
Isn't there something like ifcvars.{,c}sh in the ia32/bin directory? In
my port for icc I echo a message which advises the user to source it if
he wants to use icc. This way he also can point to a license file in his
home directory. IMHO this is a better approach than forcing a global
license directory.
>> #!/bin/sh
>> LD_LIBRARY_PATH=/compat/linux/opt/intel/compiler50/ia32/lib/
>> LM_LICENSE_FILE=/compat/linux/opt/intel/licenses/l_for.lic
>> export LD_LIBRARY_PATH LM_LICENSE_FILE
>> /compat/linux/opt/intel/compiler50/ia32/bin/ifc $@
>
> I did this instead. I installed into /compat/linux/usr/local/intel,
> since no-one uses /opt, and put the following script in
> /usr/local/bin/icc:
>
> #! /bin/sh
> if [ -z "${IA32ROOT}" ] ; then
> . /compat/linux/usr/local/intel/compiler50/ia32/bin/iccvars.sh
> fi
> exec /compat/linux/usr/local/intel/compiler50/ia32/bin/icc "$@"
>
> Then simply running (for example) "icc test.c -o test" generates a
> Linux executable.
Oh, btw, my target for icc is to create native code (and therefore I
don't install it into ${LINUXBASE}). This isn't really possible because
icc wants to link against the GNU libc, but at least I'm able to
generate native .o files (and both types of libraries). LAME is 20%
faster (at least for one specific set of options for LAME and one
specific audio file) here.
>> 2. Though the install script (with patches) installs everything to
>> /compat/linux/opt/intel, the compiler tends to complain of not finding
>> the file /usr/intel/ia32/lib/crtxn.o . I fixed this by making
>> a directory /compat/linux/usr/intel and symlinking
>> /compat/linux/opt/intel/compiler50/ia32 to /compat/linux/usr/intel/ia32.
>> This works but I'm wondering whether there's a "cleaner" solution.
>
> I didn't have this problem. Could be a difference in how we installed
> it.
It's much easier to not use the install script. I feed the RPM's through
rpm2cpio and cpio, correct some permissions, patch iccvars.* and *.cfg
to use the correct path, patch include/yvals.h to not include features.h
and then I use tar to copy the files to $PREFIX.
>> 3. The compiler by itself compiles, but does not link; it complains
>> about lots of undefined symbols. To get around this, I use the linux
They are all glibc symbols (at least this is the case for icc), but they
are all located in ia32/lib/*, the generated object files are ok. I was
also able to generate a native library which uses SSE/MMX/...
instructions depending on the used processor (determined at run time).
>> ld, which is not part of linux_base-7 or any other port as far as I
>> see (the linux_devtools seems to be for linux_base-6), so I installed
>> that separately (I could make a separate port of it). Again, lots
>> of options need to be specified properly on the linker command line,
>> so I made a script to do all that called ifclink.
>>
>> So the end-user's instructions to compile, say, test.f would be
>> /usr/local/bin/ifc -c test.f
>> /usr/local/bin/ifclink -o test test.o
>>
>> Among the things the linker script needs to do are: specify the
>> entry symbol (-e main as command line option to ld); specify the Intel
>> libraries to link against; and brand the binary as linux.
If you use gcc to link the program, you didn't have to brand the binary,
because it will be a native binary then.
> You could simply use /compat/linux/bin/ld here :)
>
>> 4. After all this, the binary still complains saying
>>
>> ELF interpreter /compat/linux/usr/lib/libc.so.1 not found
>> Abort
>>
>> I solve this with a symlink from /compat/linux/ld-2.2.2.so to
>> /compat/linux/usr/lib/libc.so.1
>> Is there a "cleaner" solution?
>
> I didn't have this problem either.
AOL
>> Do I go ahead with the above as it is, or does anyone have better
>> ideas? In particular it will be very nice if someone can get the
>> Intel compiler to link the code properly.
No way... at least as long as intel doesn't add an option to not use the
default libraries and startup code. Another possiblity would be to write
a wrapper library with the missing symbols (which are mapped in some way
to the appropriate FreeBSD functionality).
>> I think the Intel C++ compiler should be portable along the above
>> lines too. In fact I got it to compile C code into .o files quite
>> easily, which could then be linked with FreeBSD's native ld and
>> libraries to produce a working native FreeBSD binary. It didn't work
>> with C++, but the above approach may have a better chance.
That's because of a different ABI.
I have "WANT_DWARF2_UNWIND=YES" in my make.conf on -current, I haven't
tested it, but it should work with C++ here.
> This is definitely dependant on what you're building. icc will try and
> use the Linux headers, so if you use FILE, or pretty much any system
This depends on how you install icc. Here it doesn't use the linux
headers.
> struct, it's not going to run right. Actually, what might work is "icc
> -X -I /usr/include", and then link with the freebsd ld. But icc
> doesn't understand all gcc-isms, which is why Intel had to rewrite a
> lot of them and put them in intel/compiler50/ia32/substitute_headers.
It's a while since I've looked at substitute_headers, but I can only
remember changes like "#if defined(_GCC)" -> "#if defined(_GCC) ||
defined(_ICC)".
> You'de have to do the same for any offending FreeBSD headers.
Without substitute_headers icc produces very fast code already. At the
time I installed icc for the first time I wanted to have a look at which
headers should go into substitute_headers, but IMHO it wasn't worth the
time, so I just have an empty substitute_headers directory now.
Bye,
Alexander.
--
It's not a bug, it's tradition!
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201242136.g0OLaRd01258>