libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) -DPIC


From: Robert Boehne
Subject: Re: [PATCH] Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) -DPIC
Date: Fri, 17 Jan 2003 10:04:04 -0600

Kevin,

How about an option to "configure" --define-for-pic="-DPIC"?  Users
could defeine whatever symbol they like, rather than Libtool specifying
this.  This solves both problems and only requires passing a flag in
those instances where "PIC" is still being used.  Is that an agreeable
solution?

Robert

Robert Boehne wrote:
> 
> Kevin,
> 
> Yet again I am suprised by the diversity of uses for Libtool,
> I hadn't imagined this m4->asm script.  I am curious as to what tag
> it uses, the plain old C (empty) tag?
>    I think yours is the most valid point I've seen so far for
> keeping some libtool-defined macro around, but if you only support
> gcc, then your script could grep CFLAGS for -fpic or -fPIC to see if
> you're attempting to generate PIC code.  If I can get you to sign
> off on that idea I'd be perfectly willing to help with the
> implementation.
>    Regarding namespaces for macros, I don't have a C standard around,
> but I think that "__" is reserved for compilers in the standard, and
> that
> nothing else (i.e. "_") is specified.
>   My gcc 3.2 seems to agree for the most part:
> address@hidden ~/libtool]$ echo "int main(){ return 0; }" > test.c
> address@hidden ~/libtool]$ gcc -E -fpic -dM test.c
> #define __HAVE_BUILTIN_SETJMP__ 1
> #define __unix__ 1
> #define unix 1
> #define __i386__ 1
> #define __SIZE_TYPE__ unsigned int
> #define __ELF__ 1
> #define __GNUC_PATCHLEVEL__ 0
> #define __linux 1
> #define __unix 1
> #define __linux__ 1
> #define __USER_LABEL_PREFIX__
> #define linux 1
> #define __STDC_HOSTED__ 1
> #define __tune_i686__ 1
> #define __WCHAR_TYPE__ long int
> #define __pic__ 1
> #define __gnu_linux__ 1
> #define __WINT_TYPE__ unsigned int
> #define __GNUC__ 3
> #define __tune_pentiumpro__ 1
> #define __PIC__ 1
> #define __GXX_ABI_VERSION 102
> #define i386 1
> #define __GNUC_MINOR__ 2
> #define __STDC__ 1
> #define __PTRDIFF_TYPE__ int
> #define __REGISTER_PREFIX__
> #define __NO_INLINE__ 1
> #define __i386 1
> #define __VERSION__ "3.2"
> 
> Kevin Ryde wrote:
> >
> > "Boehne, Robert" <address@hidden> writes:
> > >
> > > Wouldn't replacing -DPIC with -D__PIC__ break a fundamental
> > > assumption about ANSI compilers, that "__" means compiler-defined
> > > and not in the userspace?
> >
> > I had an idea FOO was for applications, _FOO for the compiler, and
> > __FOO for third party libraries.
> >
> > Depends whether libtool is considered an application facility or
> > something vaguely separate I suppose.
> >
> > Maybe __LIBTOOL_PIC would keep right out of anyone's way, at the risk
> > of looking a bit ugly.  (Can always make a private alias of course,
> > which is probably what I would do, since I personally like plain PIC
> > well enough.)
> >
> > _______________________________________________
> > Libtool mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/libtool
> 
> _______________________________________________
> Libtool mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/libtool




reply via email to

[Prev in Thread] Current Thread [Next in Thread]