[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Additional link flags for HP aCC and SGI CC
From: |
Albert Chin |
Subject: |
Re: Additional link flags for HP aCC and SGI CC |
Date: |
Fri, 3 Sep 2004 15:26:53 -0500 |
User-agent: |
Mutt/1.5.6i |
On Fri, Sep 03, 2004 at 12:58:58PM -0500, Bob Friesenhahn wrote:
> On Fri, 3 Sep 2004, Gary V. Vaughan wrote:
>
> >Albert Chin wrote:
> >>On Thu, Sep 02, 2004 at 06:04:44PM +0200, Ludovic Court?s wrote:
> >>The following patch will pass all -[arg] and +[arg] switches through.
> >>Is it safe?
> >
> >On a mostly philosophical point, I think that allowing arguments that
> >libtool doesn't recognize through to the compiler removes some of the
> >advantages that libtool brings to a project: it is the thin end of the
> >wedge to starting to put non-portable flags into Makefile.am.
>
> What is wrong with using non-portable flags? Why would non-portable
> necessarily appear in Makefile.am rather than configure.ac? The world
> revolves around non-portable flags but it rejects non-portable
> behavior.
Libtool is about portably creating archive/shared libraries. Having it
be a _uniform_ frontent to all supported C, C++, etc. compilers is,
methinks, a really really bad idea. I think libtool should recognize
the options that matter for it to do its job and pass everything else
through, barring some technical reason for why this is not possible.
> >Besides, you can already do this, but at the moment you have to do it
> >consciously and say `-Xcompiler -peculiar-flag-for-my-compiler', which
> >at least forces the user to acknowledge that they are going behind
> >libtool's back, so it will be hardly surprising to them if libtool gets
> >confused later on...
>
> I suspect that you are unnecessarily limiting your development to the
> Linux/GCC platform. You may find it somewhat entertaining and
> enlightening to accomplish non-default compilation (e.g. 64-bit) using
> something other than GCC. What you will learn is that -Xcompiler and
> -Xlinker often confuses the build (e.g. building/linking partially
> 32-bit/64-bit code) and that it takes a very careful incantation with
> a very careful replication of -Xcompiler and -Xlinker options in the
> right places in order to achieve success. What I (and Albert) have
> seen is that things can behave very poorly because the compiler
> sometimes should alter its behavior based on linker options, but the
> compiler does not pay attention to options it is instructed to blindly
> pass through to the linker.
-Xcompiler and -Xlinker make sense only because it is sometimes common
to want a portable equivalent to -Wc/-Wl (and, if every compiler we
supported understood -Wc and/or -Wl, it'd drop the corresponding
libtool command-line equivalent). However, on Solaris, why should we
come up with a portable solution to creating 64-bit object files?
There are only two choices, the Sun compiler and GCC. Ditto for HP-UX,
IRIX, and AIX.
--
albert chin (address@hidden)
- Re: Additional link flags for HP aCC and SGI CC, Ludovic Courtès, 2004/09/02
- Re: Additional link flags for HP aCC and SGI CC, Albert Chin, 2004/09/02
- Re: Additional link flags for HP aCC and SGI CC, Gary V. Vaughan, 2004/09/03
- Re: Additional link flags for HP aCC and SGI CC, Albert Chin, 2004/09/03
- Re: Additional link flags for HP aCC and SGI CC, Peter O'Gorman, 2004/09/03
- Re: Additional link flags for HP aCC and SGI CC, Albert Chin, 2004/09/03
- Re: Additional link flags for HP aCC and SGI CC, Gary V. Vaughan, 2004/09/03
- Re: Additional link flags for HP aCC and SGI CC, Bob Friesenhahn, 2004/09/03
- Re: Additional link flags for HP aCC and SGI CC, Bob Friesenhahn, 2004/09/03
- Re: Additional link flags for HP aCC and SGI CC,
Albert Chin <=
- Re: Additional link flags for HP aCC and SGI CC, Bob Friesenhahn, 2004/09/03
- Re: Additional link flags for HP aCC and SGI CC, Gary V . Vaughan, 2004/09/05
Re: Additional link flags for HP aCC and SGI CC, Gary V . Vaughan, 2004/09/05
Re: Additional link flags for HP aCC and SGI CC, Gary V. Vaughan, 2004/09/03