Yann Dirson [EMAIL PROTECTED] writes:
As for the packaging of those libs and of the binaries that were
reduced, I'm not sure what would be best. IIRC most stuff included in
boot-floppies is taken right from real packages installed on the
machine where they are built. The e2fsprogs-bf I've
On Tue, Jun 19, 2001 at 01:41:53PM -0400, Adam Di Carlo wrote:
I don't really see the problem with having an e2fsprogs-bf package,
just for root.bin, which no one should ever normally install...
Well, my fear was that people would install e2fsprogs-bf on their
system, but now that I think of
Isn't PIC used for a reason in shared libs? :)
Sure it is, but that reason doesn't really apply here.
The reason we compile shared libraries as PIC is so that many applications can
map the same object at different addresses and have only one copy of the code
in memory. PIC code is slightly
Uh, wrong. We compile _all_ shared libs using -fPIC (IOW, every .so).
That has nothing to do with mklibs.sh, it has to do with being a shared
lib. If you try to link a .so with non-PIC objects, some architectures
will barf all of the resulting library.
The glibc testsuite checks that it works to
I understand this is policy -- specifically policy.text.gz, 4.2. This policy
makes perfect sense for a.out shared libraries (where were all the rage when
this policy was written). Does this policy still make sense?
Actually, this is a bit backwards. Linux a.out shared libraries never
On Sun, Jun 17, 2001 at 12:27:57PM +0100, Philip Blundell wrote:
Isn't PIC used for a reason in shared libs? :)
Sure it is, but that reason doesn't really apply here.
The reason we compile shared libraries as PIC is so that many
applications can map the same object at different addresses
The other issue is that the lite libext2fs.so.2.4 should never ever
be installed on a normal system, since it's missing a lot of necessary
object files. In fact, when I was chatting with Larry McVoy, he
warned me that I might be unloosing a time-bomb that might come back
to haunt me. My
[cc-ing boot-floppies team to let them know]
On Fri, Jun 15, 2001 at 07:44:43PM -0400, [EMAIL PROTECTED] wrote:
I've rejected this patch, for two reasons.
(1) It's not needed any more since you can now configure e2fsprogs to
generate a lite version of libext2fs.so.2.4.
OK I'll replace
(2) The patch is busted (not correct). The object files being placed
into the libext2fs_pic.a file are the non-shareable .o files, not
the PIC .o files. You need to cd into the elfshared subdirectory to
get at the PIC files, and the Makefile fragment doesn't do that.
Woops... I
On Sat, Jun 16, 2001 at 02:28:08PM +0100, Philip Blundell wrote:
(2) The patch is busted (not correct). The object files being placed
into the libext2fs_pic.a file are the non-shareable .o files, not
the PIC .o files. You need to cd into the elfshared subdirectory to
get at
Wouldn't building the .so with non-PIC break quite a few things?
Shouldn't do, as far as I can see. Anything in particular you are thinking of?
p.
PGP signature
On Sat, Jun 16, 2001 at 02:28:08PM +0100, Philip Blundell wrote:
Actually, for boot-floppies' purposes it would be slightly better to build
the shared library with non-PIC objects. You may not have done it
intentionally but it sounds like you got the right result. :-)
Hm... let me know
On Sat Jun 16, 2001 at 10:52:25AM -0400, Ben Collins wrote:
On Sat, Jun 16, 2001 at 02:55:30PM +0100, Philip Blundell wrote:
Wouldn't building the .so with non-PIC break quite a few things?
Shouldn't do, as far as I can see. Anything in particular you are thinking of?
Isn't PIC used
On Sat, Jun 16, 2001 at 12:53:08PM -0600, Erik Andersen wrote:
On Sat Jun 16, 2001 at 10:52:25AM -0400, Ben Collins wrote:
On Sat, Jun 16, 2001 at 02:55:30PM +0100, Philip Blundell wrote:
Wouldn't building the .so with non-PIC break quite a few things?
Shouldn't do, as far as I can
On Sat Jun 16, 2001 at 03:04:28PM -0400, Ben Collins wrote:
Uh, wrong. We compile _all_ shared libs using -fPIC (IOW, every .so).
That has nothing to do with mklibs.sh, it has to do with being a shared
lib. If you try to link a .so with non-PIC objects, some architectures
will barf all of the
On Sat, Jun 16, 2001 at 01:22:50PM -0600, Erik Andersen wrote:
On Sat Jun 16, 2001 at 03:04:28PM -0400, Ben Collins wrote:
Uh, wrong. We compile _all_ shared libs using -fPIC (IOW, every .so).
That has nothing to do with mklibs.sh, it has to do with being a shared
lib. If you try to link a
On Sat Jun 16, 2001 at 03:26:59PM -0400, Ben Collins wrote:
We have _always_ required (by policy) that objects for shared libs be
compiled with -fPIC. Where have you been? That's the whole definition of
a shared library is that it is relocatable.
One of the many beautiful things about ELF
On Sat, Jun 16, 2001 at 02:49:32PM -0600, Erik Andersen wrote:
PIC code has a major performance impact since one entire register is devoted
exclusively to holding the base address. The performance impact is exacerbated
on lame arches such as x86 which have far too few registers. Only
18 matches
Mail list logo
