severity 175077 wishlist
thanks
On Mar 07, Daniel Kobras <[EMAIL PROTECTED]> wrote:
> Marco, what's your current feeling towards #175077 (non-PIC code in
> libdv) that you submitted back then when prelink entered Debian? It's a
> case of hand-optimized assembly in a multimedia lib, and here I've
On Mon, Mar 07, 2005 at 12:10:00PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 07 Mar 2005, Paul Brossier wrote:
> > On Mon, Mar 07, 2005 at 02:05:44PM +0100, Florian Weimer wrote:
> > > >> Why do you insist to have that code be position-independant ?
> > > > I could say because it is a 'mu
On Mon, Mar 07, 2005 at 07:05:40PM +0100, Marco d'Itri wrote:
> On Mar 07, Paul Brossier <[EMAIL PROTECTED]> wrote:
>
> > 10.2. Libraries
> > ---
> >
> > The shared version of a library must be compiled with `-fPIC', and the
> > static version must not be. In other words, e
On Mar 07, Paul Brossier <[EMAIL PROTECTED]> wrote:
> 10.2. Libraries
> ---
>
> The shared version of a library must be compiled with `-fPIC', and the
> static version must not be. In other words, each source unit (`*.c',
> for example, for C files) will need to be com
On Mon, Mar 07, 2005 at 02:07:31PM +, Paul Brossier wrote:
> hrm, but yeah of course, one could say that it's fine if a
> library compiled with -fPIC still contains non position
> independant code. :)
This came up briefly on -policy some time ago as the result of #175074
and #175077, but witho
* Henrique de Moraes Holschuh:
> Just a small question: does the system KNOW an object compiled with
> -fPIC but which contains non-PIC code must be treated as a non-PIC
> object?
On x86, the dynamic linker can perform the necessary relocations when
a DSO is loaded which contains position-depende
On Mon, 07 Mar 2005, Paul Brossier wrote:
> On Mon, Mar 07, 2005 at 02:05:44PM +0100, Florian Weimer wrote:
> > >> Why do you insist to have that code be position-independant ?
> > > I could say because it is a 'must' in the debian policy, but...
> > There is no such requirement in the Policy. 8-)
On Mon, Mar 07, 2005 at 02:05:44PM +0100, Florian Weimer wrote:
> * Paul Brossier:
>
> >> Why do you insist to have that code be position-independant ?
> >
> > I could say because it is a 'must' in the debian policy, but...
>
> There is no such requirement in the Policy. 8-)
10.2. Libraries
* Paul Brossier:
>> Why do you insist to have that code be position-independant ?
>
> I could say because it is a 'must' in the debian policy, but...
There is no such requirement in the Policy. 8-)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
On Wed, Mar 02, 2005 at 10:47:34PM +0100, Bill Allombert wrote:
> Hello Paul,
>
> You need to refer to KP707106781KP707106781 through the GOT, something
> like
> pfmul [EMAIL PROTECTED](%ebx), %mm3
Ok, i gave it a try, it compiles and runs fine, but i still get
the 'objdump -p libfftw3f.so | grep
Florian Weimer <[EMAIL PROTECTED]> writes:
>> - how much can it hurt to have this non-pic in fftw3 ?
>
> It shouldn't matter much if all PIC code is grouped together in the
> binary because few pages have to be copied in this case. PIC code
> itself is always slower, significantly so if the code
On Wed, Mar 02, 2005 at 07:25:00PM +, Paul Brossier wrote:
> On Wed, Mar 02, 2005 at 05:16:50PM +0100, Florian Weimer wrote:
> > * Paul Brossier:
> >
> > > Two questions:
> > > - can anyone spot what in these codelets causes the non-pic ?
> >
> > Tables of constants are addressed directly, n
On Wed, Mar 02, 2005 at 05:16:50PM +0100, Florian Weimer wrote:
> * Paul Brossier:
>
> > Two questions:
> > - can anyone spot what in these codelets causes the non-pic ?
>
> Tables of constants are addressed directly, not in some IP-relative
> way.
thanks, i thought this could be sort of a prob
* Paul Brossier:
> Two questions:
> - can anyone spot what in these codelets causes the non-pic ?
Tables of constants are addressed directly, not in some IP-relative
way.
> - how much can it hurt to have this non-pic in fftw3 ?
It shouldn't matter much if all PIC code is grouped together in t
Hi all,
I am trying to get rid of fftw3 non position independant code
brought on i386 by the --enable-k7 configure flag. As dropping
these K7 optimisations gets rid of the non-pic, the problem seems
to lie in dft/k7/codelets/, which are generated by ocaml scripts
found in genfft-k7/.
Two question
15 matches
Mail list logo
