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] |
>>>>> 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] |