This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PIC without shared libraries


>>>>> Philip Blundell writes:

 > Hi,
 > I'm currently working on a port of libc to an embedded system.  We are using 
 > ELF binaries and all user code (libraries and applications) is compiled with 
 > -fPIC.  However, we don't wish to use shared libraries or dynamic linking so I 
 > have configured with --disable-shared --enable-static-nss. 

 > The libc configure script detects that -fPIC is default and adds `-DPIC' to 
 > the CPPFLAGS.  Unfortunately, it seems that in many cases the code is actually 
 > using "#ifdef PIC" as a test for "is this a shared object", not for PIC per 
 > se, and this causes things to go somewhat wrong.

 > I think we should either introduce a new macro that can be tested (say SHARED) 
 > and use it instead of testing for PIC, or take out the configure clause that 
 > defines PIC whenever -fPIC is in use.  I'm not sure which of these is the 
 > right thing to do; does anybody have any comments?

This is AFAIK one of the major problems the MIPS port also has.  I've
got a patch from Ralf lying around which changes many PIC to SHARED.

Ralf wrote half a year ago (with Subject: PIC default check):
> What still needs to be done to make this change actually useful is trying
> to avoid multiple compilation where the same flags would have been used for
> .o and os object files.  Furthermore, since the PIC code model and shared
> libs are related, but different things adding a second preprocessor define
> like SHARED (CPPFLAGS-.os += -DSHARED) that indicates compilation for a
> shared library would be helpful.  The places where the difference between
> PIC and SHARED matters like in init-first.c, dl-close.c etc. can then be
> cleaned up.  Does anybody see problems with that?

And Uli replied later (with Subject "Re: A patch for PIC default"):
> hjl@lucon.org (H.J. Lu) writes:
> 
> > Glibc assumes PIC means for shared libraries. It is not always correct.
> 
> Right.  PIC means shared lib, and most probably (unless I miss
> something) always shared lib (unless when used in assembler code).
> 
> But this shouldn't be a problem.  On systems where static code is not
> compiled the same way as PIC the distinction is what we want.  Again,
> this is only for assembler code and versioning stuff.
> 
> For systems which use the same code (e.g., MIPS) there is no need to
> compile any file using PIC except it depends on this symbol for
> generating versioning information.  There will not be assembler code
> depending on this symbol.  And for the versioning information case I
> suggested to provide a way to generate the .os files which then would
> get the -DPIC on the commandline.

I can try to dig the articles out if you don't have a personal archive 
of libc-hackers and can't find them in the web archive at sourceware.

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]