On Sun, Dec 05, 2021 at 12:16:38PM +0100, Thomas Koenig wrote:
>
> On 05.12.21 01:35, Peter Bergner wrote:
> > Instead of setting LD_LIBRARY_PATH=/home/tkoenig/lib64 could you try
> > setting it to LD_LIBRARY_PATH='$ORIGIN/lib64' instead? This would
> > allow the other system binaries to not
On 05.12.21 01:35, Peter Bergner wrote:
Instead of setting LD_LIBRARY_PATH=/home/tkoenig/lib64 could you try
setting it to LD_LIBRARY_PATH='$ORIGIN/lib64' instead? This would
allow the other system binaries to not find your /home/tkoenig/lib64
directory so they'd behave normally. However,
On 12/4/21 11:40 AM, Thomas Koenig wrote:
> OK, what I have now is
>
> tkoenig@gcc-fortran:~$ echo $PATH
> /home/tkoenig/bin:/opt/at15.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
> tkoenig@gcc-fortran:~$ echo $LD_LIBRARY_PATH
>
On 12/4/21 10:19 AM, Jakub Jelinek wrote:
> But when Thomas is working on the vanilla gcc tree, trying to make it work
> for Fortran, I think he'll need to patch that gcc tree too to use the
> AT15's dynamic linker and rpath like the AT15 gcc is.
That is part of the magic that happens when you
On 04.12.21 17:12, Peter Bergner via Fortran wrote:
As long as you keep the AT15 bin path before the system bin dirs, you should
be fine.
OK, what I have now is
tkoenig@gcc-fortran:~$ echo $PATH
On Sat, Dec 04, 2021 at 10:12:37AM -0600, Peter Bergner via Gcc wrote:
> On 12/4/21 9:37 AM, Peter Bergner wrote:
> > On 12/4/21 9:25 AM, Michael Meissner wrote:
> > ubuntu@gcc-fortran:/home/tkoenig/Tst$ ldd ./a.out
> > ./a.out: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not
> >
On 12/4/21 9:37 AM, Peter Bergner wrote:
> On 12/4/21 9:25 AM, Michael Meissner wrote:
> ubuntu@gcc-fortran:/home/tkoenig/Tst$ ldd ./a.out
> ./a.out: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
> (required by ./a.out)
> linux-vdso64.so.1 (0x7f633962)
>
On 12/4/21 9:25 AM, Michael Meissner wrote:
> On Sat, Dec 04, 2021 at 02:42:13PM +0100, Thomas Koenig wrote:
> Note, the system ldd does not tend to accurately report the library
> dependencies for AT libraries:
And using AT15's ldd, it shows your a.out is linked to the correct libc:
On Sat, Dec 04, 2021 at 02:42:13PM +0100, Thomas Koenig wrote:
> On 04.12.21 11:29, Jakub Jelinek wrote:
> > If zlib devel isn't installed, drop --with-system-zlib option
> > or use --without-system-zlib.
> >
> > You've asked in another mail how to configure gcc to default to
> >
On 04.12.21 11:29, Jakub Jelinek wrote:
If zlib devel isn't installed, drop --with-system-zlib option
or use --without-system-zlib.
You've asked in another mail how to configure gcc to default to
-mabi=ieeelongdouble, that is
--with-long-double-format=ieee
Thanks for those hints.
I have now
On Sat, Dec 04, 2021 at 11:16:28AM +0100, Thomas Koenig wrote:
>
> On 04.12.21 07:39, Michael Meissner via Fortran wrote:
> > I have loaded Advance Toolchain 15.0 on the system. It is located in
> > /opt/at15.0. AT 15 provides a GCC 11.2 compiler and GLIBC 2.34.
>
> I tried bootstrapping (from
On 04.12.21 07:39, Michael Meissner via Fortran wrote:
I have loaded Advance Toolchain 15.0 on the system. It is located in
/opt/at15.0. AT 15 provides a GCC 11.2 compiler and GLIBC 2.34.
I tried bootstrapping (from a separate account I set up on the
machine to make sure I don't mess up
Hi,
I have loaded Advance Toolchain 15.0 on the system. It is located in
/opt/at15.0. AT 15 provides a GCC 11.2 compiler and GLIBC 2.34.
Thanks!
I built a trunk compiler using the options:
--enable-languages=c,c++,fortran \
--disable-plugin \
On Fri, Dec 03, 2021 at 08:57:54AM -0600, Bill Schmidt wrote:
> Hi!
>
> On 12/3/21 5:56 AM, Thomas Koenig wrote:
> >
> > Hi Jakub,
> >
> >> Note, we want to test both building gcc on ppc64le with older glibc
> >> and newer glibc (and that libgfortran will have the same ABI between both
> >> and
Hi!
On 12/3/21 5:56 AM, Thomas Koenig wrote:
>
> Hi Jakub,
>
>> Note, we want to test both building gcc on ppc64le with older glibc
>> and newer glibc (and that libgfortran will have the same ABI between both
>> and one can move gcc including libgfortran and libquadmath from the older
>> glibc
Hi Jakub,
Note, we want to test both building gcc on ppc64le with older glibc
and newer glibc (and that libgfortran will have the same ABI between both
and one can move gcc including libgfortran and libquadmath from the older
glibc setup to newer and make -mabi=ieeelongdouble work in Fortran
On Fri, Dec 03, 2021 at 12:16:56PM +0100, Thomas Koenig wrote:
> > It is part of upstream glibc 2.32 (released Aug 2020) and later, see
> > https://sourceware.org/git/?p=glibc.git;a=commit;h=051be01f6b41a1466b07ae4bd7f5894a8ec5fe67
> > distrowatch says that glibc 2.32 and later is in Ubuntu 21.04
On 03.12.21 10:28, Jakub Jelinek wrote:
On Fri, Dec 03, 2021 at 08:29:53AM +0100, Thomas Koenig wrote:
On 01.12.21 21:54, Jakub Jelinek via Fortran wrote:
Inside of libgfortran, I think it should depend on some macro defined
in libgfortran.h.
#if defined(__powerpc64__) && __BYTE_ORDER__ ==
On Fri, Dec 03, 2021 at 08:29:53AM +0100, Thomas Koenig wrote:
>
> On 01.12.21 21:54, Jakub Jelinek via Fortran wrote:
>
> > Inside of libgfortran, I think it should depend on some macro defined
> > in libgfortran.h.
> > #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
>
On 01.12.21 21:54, Jakub Jelinek via Fortran wrote:
Inside of libgfortran, I think it should depend on some macro defined
in libgfortran.h.
#if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
&& defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
then
#define
On Wed, Dec 01, 2021 at 09:54:50PM +0100, Jakub Jelinek wrote:
> sinl in C when compiled with -mabi=ieeelongdouble), but I'm not sure
> if those need to be declared by libgfortran or math.h declares them).
To answer this myself, just tried on Fedora 34 and we'd need to
declare those ourselves.
On Wed, Dec 01, 2021 at 09:34:47PM +0100, Thomas Koenig via Gcc wrote:
> I am currently working on implementing the IEEE 128-bit floating
> on POWER. One of the things to decide is what to call the
> math functions for the library calls.
>
> Example: libgfortran/generated/bessel_r16.c currently
I am currently working on implementing the IEEE 128-bit floating
on POWER. One of the things to decide is what to call the
math functions for the library calls.
Example: libgfortran/generated/bessel_r16.c currently has
#if defined(GFC_REAL_16_IS_FLOAT128)
#define MATHFUNC(funcname) funcname ##
23 matches
Mail list logo
