One minor clarification -- LAM does not use any GCC / glibc extensions
that I am aware of. LAM uses standard libc calls (e.g., printf) that
are available on all POSIX platforms. There's a bunch of
platform-specific code in LAM, of course (i.e., what the configure
script finds), but I don't *think* that there are any glibc extensions
in there...?
My limited understanding of how the intel compilers work was that they
did not implement all of libc (i.e., why re-implement the wheel?) and
instead relied on the back-end libc for at least some of its
functionality (e.g., some of the non-performance-critical functions).
That may or may not be correct. :-)
I suspect that, in general, you may have difficulty compiling on one
system and running on another (different) system. Statically compiling
is only a small part of the battle; other differences between systems
can cause problems (e.g., thread implementations, pty and file
descriptor passing implementations, ioctl implementations, constant
value changes, etc.).
Even though it may have worked for you in the past, I would not
recommend this. You have a heterogeneous system (see the LAM FAQ) --
you will probably have far less headaches if you treat it as such.
Hope that helps.
On Dec 5, 2004, at 1:52 AM, Tim Prince wrote:
> At 03:22 PM 12/4/2004, Kamaraju Kusumanchi wrote:
>
>> So there is no libc.so.6 offered by intel. I have no idea why a.out
>> should even depend on it in the first place.
>
> lam has explicit calls to libc functions. In order to provide gcc
> compatibility, Intel run-time libraries also must employ libc
> consistently with gcc. FSF doesn't call it gnu linux for nothing.
>
>
> Tim Prince
> _______________________________________________
> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
>
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
