This feels like a build test sequence issue as opposed to a bug of any
real sort. I have pre-existing gmp libs installed in /usr/local from
yesterday and am doing a reconfigure and rebuild today. On a Debian 8.8
system 3.16.0-4-powerpc64 with gcc Debian 4.9.2-10 I see a complete
configure and
I have been trying to get gmp-6.1.2 to build while avoiding the use of
"disable-assembly" in the configure stage. I think I may have tripped on
something here. So I isolated everything into my home dir and gave it
a try. Mostly trying to get some decent performance.
Configure looks fine thus
On 2017-08-28 23:33:03 +0200, Niels Möller wrote:
> Vincent Lefevre writes:
> > This only works if the user is root. If a non-root user wants to
> > install libraries in his home directory, the right solution is to
> > use LD_LIBRARY_PATH (since GCC doesn't use a run path by
On 8/28/17 5:01 PM, Marc Glisse wrote:
On Sun, 27 Aug 2017, Dennis Clarke wrote:
I have been trying to get gmp-6.1.2 to build while avoiding the use of
"disable-assembly" in the configure stage. I think I may have tripped on
something here. So I isolated everything into my home dir and gave
On 8/28/17 5:21 PM, Niels Möller wrote:
Dennis Clarke writes:
On 8/28/17 4:41 PM, Niels Möller wrote:
Dennis Clarke writes:
The compiler sees that file gcd_1.asm as something unknown.
That command is bogus.
I think you missed the point.
Vincent Lefevre writes:
> This only works if the user is root. If a non-root user wants to
> install libraries in his home directory, the right solution is to
> use LD_LIBRARY_PATH (since GCC doesn't use a run path by default).
You'd either use LD_LIBRARY_PATH, which is
On 8/28/17 5:33 PM, Niels Möller wrote:
Vincent Lefevre writes:
This only works if the user is root. If a non-root user wants to
install libraries in his home directory, the right solution is to
use LD_LIBRARY_PATH (since GCC doesn't use a run path by default).
I never
Dennis Clarke writes:
somedays I don't include details and I get railed at .. other days I
do and I get railed at .. life goes on.
Did Niels rail you? I think that's a quite unfair assessment. He's
pointing out a central issue here, your snub is the attitude
Dennis Clarke writes:
> somedays I don't include details and I get railed at .. other days I
> do and I get railed at .. life goes on.
Including details is nice and helpful, just don't expect everyone to
digest all of the details at once. If I spot a single small problem
Dennis Clarke writes:
> Just going into mpn directory and re-running that last compile command
> gives me an obvious error :
>
> v9_7++ $ c99 -c -DHAVE_CONFIG_H -I. -I.. \
>> -D__GMP_WITHIN_GMP -DOPERATION_gcd_1 \
>> -I/export/home/dclarke/local/include \
>> -D_TS_ERRNO
Dennis Clarke writes:
> In some manner the pre-existing libs were getting in the way likely
> because LD_LIBRARY_PATH=/usr/local/lib and thus the new libs in the
> build_dir/.libs were not used.
LD_LIBRARY_PATH tends to override anything else. Don't use that for
anything
On Sun, 27 Aug 2017, Dennis Clarke wrote:
I have been trying to get gmp-6.1.2 to build while avoiding the use of
"disable-assembly" in the configure stage. I think I may have tripped on
something here. So I isolated everything into my home dir and gave it
a try. Mostly trying to get some
On 8/28/17 4:41 PM, Niels Möller wrote:
Dennis Clarke writes:
The compiler sees that file gcd_1.asm as something unknown.
That command is bogus.
I think you missed the point.
That libgmpxx depends on libstdc++ is perfectly normal ..
Yes, if gcc is used then
On 2017-08-28 22:50:23 +0200, Niels Möller wrote:
> Dennis Clarke writes:
>
> > In some manner the pre-existing libs were getting in the way likely
> > because LD_LIBRARY_PATH=/usr/local/lib and thus the new libs in the
> > build_dir/.libs were not used.
>
>
On 8/28/17 5:36 PM, Torbjörn Granlund wrote:
Dennis Clarke writes:
somedays I don't include details and I get railed at .. other days I
do and I get railed at .. life goes on.
Did Niels rail you? I think that's a quite unfair assessment. He's
no ... I jsut
15 matches
Mail list logo