Marcin Owsiany <[EMAIL PROTECTED]> immo vero scripsit:
> I read somewhere that code compiled with -fPIC is a little larger and
> slower. Is this the only reson for that policy requirement? If not,
> please give me for some information/pointers on that requirement.
I think th
Marcin Owsiany <[EMAIL PROTECTED]> immo vero scripsit:
> I read somewhere that code compiled with -fPIC is a little larger and
> slower. Is this the only reson for that policy requirement? If not,
> please give me for some information/pointers on that requirement.
I think th
Hi, gurus!
The Debian policy says:
] 11.2 Libraries
]
] All libraries must have a shared version in the lib* package and a
] static version in the lib*-dev package. The shared version must be
] compiled with -fPIC, and the static version must not be. In other
] words, each *.c file will need to
Hi, gurus!
The Debian policy says:
] 11.2 Libraries
]
] All libraries must have a shared version in the lib* package and a
] static version in the lib*-dev package. The shared version must be
] compiled with -fPIC, and the static version must not be. In other
] words, each *.c file will need to
or do you mean "ix86"?
> Is there a performance hit with -fPIC on Pentium II/III/IV ?
Yes, since there are no new registers (you need one register for PIC
addressing).
Simon
--
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fingerprint: 040E B5F7 8
if I cannot
> > control the granularity of compiler options easily in a build system and I
> > build an executable with -fPIC in order to build an accompanying library
> > correctly, am I trading off speed or footprint to any significant degree?
>
> On most architec
I
> build an executable with -fPIC in order to build an accompanying library
> correctly, am I trading off speed or footprint to any significant degree?
On most architectures, it doesn't really matter except for heavy
mathematics and 3D. The only exception is i386, where the performance
thing. e.g. if I cannot
> > control the granularity of compiler options easily in a build system and I
> > build an executable with -fPIC in order to build an accompanying library
> > correctly, am I trading off speed or footprint to any significant degree?
>
> On most architec
I
> build an executable with -fPIC in order to build an accompanying library
> correctly, am I trading off speed or footprint to any significant degree?
On most architectures, it doesn't really matter except for heavy
mathematics and 3D. The only exception is i386, where the performance
On Thursday 21 Mar 2002 1:07 am, Michel LESPINASSE wrote:
> For debian shared libraries, yes.
> For programs and static libraries, you should avoid using -fPIC.
Thanks, I appreciate the advice. It makes my life a bit easier too. :)
On Wed, Mar 20, 2002 at 11:11:10PM +, Will Newton wrote:
> On Wednesday 20 Mar 2002 11:00 pm, Michel LESPINASSE wrote:
> > I'd like to add that some architectures (including x86) do not actualy
> > require that you use -fPIC for shared libraries. If you choose to do
> &
On Wednesday 20 Mar 2002 11:00 pm, Michel LESPINASSE wrote:
> I'd like to add that some architectures (including x86) do not actualy
> require that you use -fPIC for shared libraries. If you choose to do
> that, the benefits are that you dont pay the overhead of -fPIC code,
&
tem and I
> build an executable with -fPIC in order to build an accompanying library
> correctly, am I trading off speed or footprint to any significant degree?
Yes, this will slow down your program by (usualy) around 5% on
x86. Probably it will increase the footprint a little as well - I have
On Thursday 21 Mar 2002 1:07 am, Michel LESPINASSE wrote:
> For debian shared libraries, yes.
> For programs and static libraries, you should avoid using -fPIC.
Thanks, I appreciate the advice. It makes my life a bit easier too. :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a s
On Wed, Mar 20, 2002 at 11:11:10PM +, Will Newton wrote:
> On Wednesday 20 Mar 2002 11:00 pm, Michel LESPINASSE wrote:
> > I'd like to add that some architectures (including x86) do not actualy
> > require that you use -fPIC for shared libraries. If you choose to do
> &
On Wednesday 20 Mar 2002 11:00 pm, Michel LESPINASSE wrote:
> I'd like to add that some architectures (including x86) do not actualy
> require that you use -fPIC for shared libraries. If you choose to do
> that, the benefits are that you dont pay the overhead of -fPIC code,
&
tem and I
> build an executable with -fPIC in order to build an accompanying library
> correctly, am I trading off speed or footprint to any significant degree?
Yes, this will slow down your program by (usualy) around 5% on
x86. Probably it will increase the footprint a little as well - I have
On Wednesday 20 Mar 2002 5:46 pm, Simon Richter wrote:
> In general, you need to compile everything that could be mapped at
> arbitrary addresses (in the process's virtual address space) with the
> -fPIC option to make it position independent (whatever that means for the
>
Hi,
on Wed, 20 Mar 2002, Will Newton wrote:
> Is it valid to compile an executable with -fPIC?
> Can anyone tell me which architectures require -fPIC?
In general, you need to compile everything that could be mapped at
arbitrary addresses (in the process's virtual address space) wit
On Wednesday 20 Mar 2002 5:46 pm, Simon Richter wrote:
> In general, you need to compile everything that could be mapped at
> arbitrary addresses (in the process's virtual address space) with the
> -fPIC option to make it position independent (whatever that means for the
>
Hi,
on Wed, 20 Mar 2002, Will Newton wrote:
> Is it valid to compile an executable with -fPIC?
> Can anyone tell me which architectures require -fPIC?
In general, you need to compile everything that could be mapped at
arbitrary addresses (in the process's virtual address space) wit
Is it valid to compile an executable with -fPIC?
Can anyone tell me which architectures require -fPIC?
Thanks,
Is it valid to compile an executable with -fPIC?
Can anyone tell me which architectures require -fPIC?
Thanks,
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hi.
I'm having problems compiling a shared python extention, because lintian
keeps complaining about foo.so not being compiled with the -fPIC option, but
IT IS, as you can see from the output:
--- cut ---
Making all in compiled
make[3]: Entering directory
/home/digito/debian/
[Sent to -mentors and -perl; I am not sure which is appropriate.]
I have been working on creating a (binary) Perl module, and have
noticed that by default, it will compile with a -fpic flag rather than
a -fPIC one.
Should I therefore append something like:
CC=gcc CCCDLFLAGS=-fPIC
to my make
Hi all
On master in ~igloo/libgtop* is the source of the latest package of
libgtop1 (not yet uploaded to incoming) with 2 errors reported by
lintian.
The first relates to the changelog, and I now know how to fix it,
but the second, something to do with PIC code, has got me and many
people on IRC
26 matches
Mail list logo
