Georg S. Weber wrote:
Unfortunately, rpath is not a general solution for shared libraries
included in Sage because the paths would then be fixed at link time -
which wouldn't all the Sage package to be arbitrarily relocated.
I know.
But on OS X, there is a tool "install_name_tool", and it see
On 2 Feb., 11:06, Peter Jeremy wrote:
> On 2010-Feb-01 20:13:07 +, David Kirkby wrote:
>
> >$ cc -flags
>
> >shows as options for the Sun compiler:
>
> >-R Build runtime search path list into executable
>
> >Actually building a gcc which will search at a specified place seem
On 2010-Feb-02 11:37:35 +, "Dr. David Kirkby"
wrote:
>I do not consider using crle a viable option, though it would work.
The problem with crle is that it's system-wide, as you point out.
>I'll look at using the dumpspecs on 't2'. It's not clear to me where I would
>edit that though. The f
Peter Jeremy wrote:
On 2010-Feb-01 20:13:07 +, David Kirkby wrote:
$ cc -flags
shows as options for the Sun compiler:
-R Build runtime search path list into executable
Actually building a gcc which will search at a specified place seems
next to impossible on Solaris. The
On 2010-Feb-01 20:13:07 +, David Kirkby wrote:
>$ cc -flags
>
>shows as options for the Sun compiler:
>
>
>-R Build runtime search path list into executable
>
>Actually building a gcc which will search at a specified place seems
>next to impossible on Solaris. The GCC developer
On 1 February 2010 19:41, Georg S. Weber wrote:
> Hi,
>
> does anyone know whether the "rpath" feature of linking/loading is
> available on Solaris?
>
> (I'm just curious. Currently, Sage resp. its "relocation feature" does
> not use "rpath" based linking/loading, but instead relies on
> LD_LIBRAR
Hi,
does anyone know whether the "rpath" feature of linking/loading is
available on Solaris?
(I'm just curious. Currently, Sage resp. its "relocation feature" does
not use "rpath" based linking/loading, but instead relies on
LD_LIBRARY_PATH and friends.)
Cheers,
Georg
--
To post to this group
On 2010-Jan-30 11:51:08 +, "Dr. David Kirkby"
wrote:
>Bill Hart wrote:
>> Cause of what David? MPIR 1.3.0 works absolutely fine on t2 if you set
>> the library paths correctly.
>
>I'm not convinced it should be necessary to set LD_LIBRARY_PATH like
>that. It is not with other 64-bit applicati
On Sat, Jan 30, 2010 at 10:49 AM, Nick Alexander wrote:
>> Building Sage on HP-UX is just going to cause an immense amount of
>> grief for a whole load of Sage developers. Why force hundreds of
>> people to work to support a substandard compiler on a system no one is
>> ever going to use Sage on,
Building Sage on HP-UX is just going to cause an immense amount of
grief for a whole load of Sage developers. Why force hundreds of
people to work to support a substandard compiler on a system no one is
ever going to use Sage on, just so you can catch a few hidden bugs,
when we have hundreds of re
I found another Ultrasparc2 which is set up correctly (same linux),
and the MPIR C++ tests pass no problems. So this confirms my belief
that gcc54 was just set up wrongly.
I'm going to close the longstanding ticket we have open for that, and
I'll just build on the other machine I have found, in fu
On Jan 30, 12:24 pm, Bill Hart wrote:
> If you don't believe me, find me even a single library which has a
> make check that uses libtool wrappers for the test programs that
> passes make check on Solaris 64 bit on t2.
Wait, that should have said:
If you don't believe me, find me even a single
2010/1/30 Dr. David Kirkby :
> BTW, a 64-bit build of mpir 1.3.0 on an HP-C3600, running HP-UX 11.11B,
> results in the results shown below. This is with a PA-RISC processor - I do
> not have access to any of the newer Itanium machines.
>
> This is really good news, as an HP-UX port of Sage seems
If you don't want to change LD_LIBRARY_PATH, change LD_LIBRARY_PATH_64
as I explained.
It's this simple:
1) GCC NEEDS** complicated binaries to link against libgcc
(read the supplied references online or google it yourself)
2) Thus the linker NEEDS*** the path to the 64 bit libgc
Sorry, I pressed send before sanitising. I didn't intend to post the
expletives. Apologies for any offence.
I am just a bit frustrated at the moment, probably for reasons that
have nothing to do with this conversation, sorry.
Bill.
2010/1/30 Bill Hart :
> 2010/1/30 Dr. David Kirkby :
>> Bill Har
2010/1/30 Dr. David Kirkby :
> Bill Hart wrote:
>>
>> Cause of what David? MPIR 1.3.0 works absolutely fine on t2 if you set
>> the library paths correctly.
>
> I'm not convinced it should be necessary to set LD_LIBRARY_PATH like that.
> It is not with other 64-bit applications. But I may be mistak
Bill Hart wrote:
Cause of what David? MPIR 1.3.0 works absolutely fine on t2 if you set
the library paths correctly.
I'm not convinced it should be necessary to set LD_LIBRARY_PATH like that. It is
not with other 64-bit applications. But I may be mistaken
BTW, a 64-bit build of mpir 1.3.0 on
Cause of what David? MPIR 1.3.0 works absolutely fine on t2 if you set
the library paths correctly.
On Jan 30, 3:28 am, David Kirkby wrote:
> On 30 January 2010 01:03, François Bissey wrote:
>
>
>
>
>
> > Hi Bill,
> > It is a bit more subtle than that, it should work most of the time. The main
>
François Bissey wrote:
On Sat, 30 Jan 2010 16:28:04 David Kirkby wrote:
I will however test this out later today (within the next 12 hours) on
the Sun Blade 2000 I own. That will at least enable us to determine if
it is the hardening in Solaris on SPARC which is causing this. The
fact this has b
François Bissey wrote:
On Sat, 30 Jan 2010 16:28:04 David Kirkby wrote:
I will however test this out later today (within the next 12 hours) on
the Sun Blade 2000 I own. That will at least enable us to determine if
it is the hardening in Solaris on SPARC which is causing this. The
fact this has b
On Sat, 30 Jan 2010 16:28:04 David Kirkby wrote:
> I will however test this out later today (within the next 12 hours) on
> the Sun Blade 2000 I own. That will at least enable us to determine if
> it is the hardening in Solaris on SPARC which is causing this. The
> fact this has been around since 1
On 30 January 2010 01:03, François Bissey wrote:
> Hi Bill,
> It is a bit more subtle than that, it should work most of the time. The main
> case where things could go south is if you have a hardened system with
> the NX bit turned on - my guess.
> It is a QA issue meaning that actual side effect
On Sat, 30 Jan 2010 15:26:51 Bill Hart wrote:
> > It is a bit more subtle than that, it should work most of the time. The
> > main case where things could go south is if you have a hardened system
> > with the NX bit turned on - my guess.
> > It is a QA issue meaning that actual side effects are ha
On Jan 30, 1:03 am, François Bissey wrote:
> Hi Bill,
>
> Let me try to clarify a bit.
>
> On Sat, 30 Jan 2010 12:18:54 Bill Hart wrote:
>
> > All of those object files seem to come from assembly code assembled by
> > yasm. I actually don't understand the bug report though. So I am not
> > sure
Hi Bill,
Let me try to clarify a bit.
On Sat, 30 Jan 2010 12:18:54 Bill Hart wrote:
> All of those object files seem to come from assembly code assembled by
> yasm. I actually don't understand the bug report though. So I am not
> sure what needs fixing. I don't know of any systems that these file
I tried a later libtool (the one distributed with the Ubuntu on
boxen.math) and this made no difference.
I also looked through the recent changelog of the libtool project and
there is no mention of this issue being fixed. I also did an extensive
search online and pretty much everyone just recommen
Also, from the Sun documentation:
Linking
The linker remains a 32-bit application, but this should be
transparent to most users, since it is normally invoked indirectly by
the compiler driver, for example, cc(1). If the linker is presented
with a collection of ELF32 object files as input, it creat
All of those object files seem to come from assembly code assembled by
yasm. I actually don't understand the bug report though. So I am not
sure what needs fixing. I don't know of any systems that these files
don't work on. Besides that, the only architectures they get used on
are x86_64!
Is the p
Just to clarify, the suggestion to use #defines when --enable-
gmpcompat is used, for functions we have deprecated and (eventually)
removed in MPIR is obviously sensible (unless GMP also deprecates
them, as we hope they will). My comment above about not including them
with --enable-gmpcompat only a
I forgot to mention, the long deprecated function mpz_random has also
finally been removed.
Bill.
2010/1/28 Bill Hart :
> Hi all,
>
> it is with pleasure that we (finally) officially release MPIR 1.3.0.
> It is available at our website http://www.mpir.org/
>
> Please note the following important
30 matches
Mail list logo
