On Wed, 2010-08-04 at 15:16 +0800, Peng Yuan wrote:
> I agree with your points.
>
> So for the checkin,
> 1) Objects in libopen64rt_shared.a should be compiled with -fPIC.
They are. We are already linking this library into shared libraries and
if it wasn't compiled with -fPIC that wouldn't be w
agreed. One of IPA's optimization is to attempt make PIC == PIE performance-wise
Sun
2010/8/4 Peng Yuan :
> I agree with your points.
>
> So for the checkin,
> 1) Objects in libopen64rt_shared.a should be compiled with -fPIC.
> 2) Make sure libopen64rt_shared.a can be used for executable. Otherwis
I agree with your points.
So for the checkin,
1) Objects in libopen64rt_shared.a should be compiled with -fPIC.
2) Make sure libopen64rt_shared.a can be used for executable. Otherwise, we
cannot modify open64 driver code for the issue. Because libopen64rt.a is
used for executable originally, and l
Yonghong Yan wrote:
concerning IA64, is the software pipeliner from SGI included in open64?
No that wasn't open sourced.
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring the
for embedded execution, PIE != PIC, otherwise, they are the same, no?
For a PIE relocatable, there is no need for dynamic relocation, that
is the job of linkers. If the shared.a is not compiled with PIC (or
PIE) it is wrong. A function being reentrant happen to be able to be
PIE is an accident (i.e
The checkin will affect the use of the library. I suspect the corectness of
using libopen64rt_shared.a for PIE executable, which the checkin works.
On Wed, Aug 4, 2010 at 12:01 PM, Sun Chan wrote:
> but this is a problem with the library itself, not the checkin.
> Sun
>
> On Tue, Aug 3, 2010 at
but this is a problem with the library itself, not the checkin.
Sun
On Tue, Aug 3, 2010 at 8:55 PM, Peng Yuan wrote:
> If libopen64rt_shared.a can be used for executable except for shared
> library, I'll support the checkin. Not perfect, but it can work for the
> current trunk. Otherwise we must
If libopen64rt_shared.a can be used for executable except for shared
library, I'll support the checkin. Not perfect, but it can work for the
current trunk. Otherwise we must notice the PIE issue.
I just explain the PIE linking. I don't konw the function of libopen64rt.a
and libopen64rt.a. Why doe
you answered my question.
Pls go ahead with the checkin
Sun
On Wed, Aug 4, 2010 at 7:04 AM, Steve Ellcey wrote:
> On Wed, 2010-08-04 at 06:52 +0800, Sun Chan wrote:
>> I suppose the same problem will occur for open64 internal flag -shared
>> sun
>
> I am not sure what you mean by the 'internal fl
On Wed, 2010-08-04 at 06:52 +0800, Sun Chan wrote:
> I suppose the same problem will occur for open64 internal flag -shared
> sun
I am not sure what you mean by the 'internal flag -shared'? Is that
something different than the user visible -shared flag used to create a
shared library? If you bui
I suppose the same problem will occur for open64 internal flag -shared
sun
On Wed, Aug 4, 2010 at 6:48 AM, Steve Ellcey wrote:
> This patch is my proposed fix for bug 577, The problem is that when
> linking a program using the -pie (-fPIE, -fpie) option to create a
> position independent executa
This patch is my proposed fix for bug 577, The problem is that when
linking a program using the -pie (-fPIE, -fpie) option to create a
position independent executable we link in libopen64rt.a which contains
non-PIC code and this causes us to get a link-time error.
My fix is to link in libopen64rt
12 matches
Mail list logo
