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] |
> Mailing-List: contact libc-hacker-help@sourceware.cygnus.com; run by ezmlm > Date: Tue, 25 May 1999 10:41:21 +0100 > From: Philip Blundell <pb@nexus.co.uk> > > 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? It would be the first one. There are a number of uses of PIC in the assembler files that really mean PIC. I think this came up before on this list, didn't it? -- Geoffrey Keating <geoffk@ozemail.com.au>
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |