Re: Problems with out libgcc_s.so in base
On Sun, Aug 14, 2016 at 07:34:30PM -0400, Diane Bruce wrote: > On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote: > > > > FreeBSD-ports could avoid libquadmath issues by building gcc > > without it. See --without-libquadmath or --without-quadmath (I > > don't remember the config option because it would be questionable > > to neuter one of gfortran's strength). > > Correct. This blog entry I read some months ago outlines this > exact problem we are having and suggests the identical solution. > > http://glennklockwood.blogspot.ca/2014/02/linux-perf-libquadmath-and-gfortrans.html > > quadmath does have an impact on performance. > I read that blog a long time ago. It is quite humorous, because the author does not understand the storage requirements of Fortran. If one uses only the -fdefault-real-8 option to promote REAL to DOUBLE PRECISION, then storage requirements mandate that DP should be promoted to QP (if available). That's why there is the -fdefault-double-8. In additions, these options were never meant to be used in a situation where performance matters. These options are a crutch for lazy programmers, who don't want to properly port code to a wider precision. As the person who actually implemented these options in gfortran for backwards compatibility with g77, I can assure that very few people know what these options do. The problem lies in Fortran's COMMON and EQUIVALENCE statements, where storage alignment can be messed up by the -fdefault-* options. Other than properly porting code to a wider type, people should use the -freal-* (eg, -freal-4-real-8). I submitted a patch to fortran@gcc to deprecate the -fdefault-* option in January. The deprecation who have occurred over 2 major releases. But, too many people objected under POLA. > > Freebsd-ports could also use a wrapper: > > % cat ~/bin/gfc7 > > #! /bin/sh > > Yes. I have also suggested we use a wrapper to the ports guys. > There always the option to link apps that need libgfortran with the -static option. -- Steve ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Problems with out libgcc_s.so in base
On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote:
>
> > The reason ports gcc now has this requirment on 4.6 or better is
> > fortran standard says we have to support quad floating point math.
> > e.g. /usr/local/lib/gccXX/libquadmath.so
>
> Diane,
>
> Can you please stop with the dis-information? No Fortran standard
I'm happy to be corrected. In this case it's immaterial if it is a
Fortran standard or not. It is what our present gcc from ports has given us.
...
>
> FreeBSD-ports could avoid libquadmath issues by building gcc
> without it. See --without-libquadmath or --without-quadmath (I
> don't remember the config option because it would be questionable
> to neuter one of gfortran's strength).
Correct. This blog entry I read some months ago outlines this
exact problem we are having and suggests the identical solution.
http://glennklockwood.blogspot.ca/2014/02/linux-perf-libquadmath-and-gfortrans.html
quadmath does have an impact on performance.
>
> Freebsd-ports could also use a wrapper:
> % cat ~/bin/gfc7
> #! /bin/sh
> DIR=`id -P sgk | sed 's/\:/\ /g' | awk '{print $9}'`
> export DIR
>
> LD_LIBRARY_PATH=$DIR/work/7/lib
> export LD_LIBRARY_PATH
>
> LD_RUN_PATH=$DIR/work/7/lib
> export LD_RUN_PATH
>
> $DIR/work/7/bin/gfortran -fno-backtrace $@
Yes. I have also suggested we use a wrapper to the ports guys.
- Diane
--
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Problems with our libgcc_s.so in base
Problems with libgcc_s.so in base
If you compile with gcc and use our base libgcc it should DTRT
*provided* our libgcc has defined functions that are up to date
with current libgcc
We compile with gcc, it needs foo() from libgcc to run
doesn't matter what foo() is (A typical function would be T __multi3)
So our libgcc provides a foo() and gcc is happy
This means in theory, we can interchangeably use gcc and clang in ports.
This also means it made the initial port work from from gcc in base
to clang in base a lot easier.
The problems come when we try to use architectures not fully
supported by our libgcc_s.so or when we use fortran.
However, our libgcc lies in two ways
1) our libgcc is mostly not GPL code anymore, though there are
bits and pieces of GPL depending on what we don't have.
This includes (or did) some of the work ian@ was trying to do with arm,
various bits that arm libgcc provides from gcc were missing.
2) It claims to be only up to date with GCC 4.2.4
Everything is peachy keen until someone references a symbol which is in
anything gcc compiled using a newer > GCC 4.2.4 compiler.
The moment you load libgfortran, it has a requirement for GCC_4.6 or better,
and if our libgcc is already loaded things fail.
The reason ports gcc now has this requirment on 4.6 or better is
fortran standard says we have to support quad floating point math.
e.g. /usr/local/lib/gccXX/libquadmath.so
We *could* lie in our libgcc_s and claim to be 4.6 which would simply
mean libgfortran would not complain and simply load the missing libquadmath.
If we updated the claimed GCC version in our libgcc_s.so to claim
GCC_4.6, we really also should provide a libquadmath subsitute.
The other approach is to rename our libgcc_s.so to libclang_s.so or
some such and link base with it instead of libgcc_s.so
I frankly think this in the long term is the cleaner solution.
In the ports world, we have papered over this problem by adding
-Wl,-rpath=${_GCC_RUNTIME} or similar to force programs to link
against /usr/local/lib/gcc${GCCVERSION}/libgcc_s.so
However, any program that uses python to build has to be patched
to force this stanza and our ports cmake presently does not force
this stanza to be added.
Diane
--
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
