Re: Problems with out libgcc_s.so in base

[Dimitry Andric]

On 22 Aug 2016, at 08:26, Matthias Andree  wrote:
> 
> Am 18.08.2016 um 14:48 schrieb Dimitry Andric:
>> For example, on one of my systems, I now have these:
>> 
>> /usr/local/lib/gcc47/libgcc_s.so.1
>> /usr/local/lib/gcc48/libgcc_s.so.1
>> /usr/local/lib/gcc49/libgcc_s.so.1
>> /usr/local/lib/gcc5/libgcc_s.so.1
>> /usr/local/lib/gcc6/libgcc_s.so.1
>> /usr/local/lib/gcc7/libgcc_s.so.1
> 
> This in itself - to me - seems to be the actual problem, how do
> different versions of the library the same major version?

The gcc folks use symbol versioning, see:

https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

This works incrementally, so libgcc from gcc N is backwards compatible
with all previous libgcc's from gcc < N.  Not the other way around, of
course.

On Linux systems, there are no compatibility problems as we have seen
them, because you simply install the most recent libgcc into /lib, and
all applications will use that.  Older applications will find their
older ABI through symbol versioning.

However, even on a Linux system you could get into trouble if you would
compile and install a newer version of gcc than the system's default.

Applications linked with that newer version would possibly require a
newer libgcc ABI, and you would have the same problem that we have now.

-Dimitry

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Matthias Andree]

Am 18.08.2016 um 14:48 schrieb Dimitry Andric:
> For example, on one of my systems, I now have these:
>
> /usr/local/lib/gcc47/libgcc_s.so.1
> /usr/local/lib/gcc48/libgcc_s.so.1
> /usr/local/lib/gcc49/libgcc_s.so.1
> /usr/local/lib/gcc5/libgcc_s.so.1
> /usr/local/lib/gcc6/libgcc_s.so.1
> /usr/local/lib/gcc7/libgcc_s.so.1

This in itself - to me - seems to be the actual problem, how do
different versions of the library the same major version?

If these were, say:

/usr/local/lib/gcc47/libgcc_s.so.2
/usr/local/lib/gcc48/libgcc_s.so.3
/usr/local/lib/gcc49/libgcc_s.so.4
/usr/local/lib/gcc5/libgcc_s.so.5
/usr/local/lib/gcc6/libgcc_s.so.6
/usr/local/lib/gcc7/libgcc_s.so.7

Or possibly the compatible ones folded into 2.0, 2.1, 2.2, 3.0 ... and
our linker be taught that it can always grab a newer minor version, but
not a different major version component, then that would also help
because you then match the proper libgcc_s. Does libgcc_s version
symbols when semantics change over releases?

The counter-argument will be that it will be much harder to use
indirectly linked libgcc_s (say, project A needs lib B and lib C, lib B
depends on older libgcc_s than lib C) - but as I understood from past
discussions (around libssl.so.X in that case) that causes crashes at
run-time if the libraries aren't compatible, so this argument is invalid.
> Steve's proposed scheme solves that quite nicely, in my opinion.  The
> problem is only in the details, as usual.  There will be many configure
> scripts and libtool-like utilities out there, that assume libgcc must be
> linked using -lgcc_s, not -lgcc_s$VERSION.
Which can be solved with proper -L options and does not incur renaming
libraries.



signature.asc
Description: OpenPGP digital signature

Re: Problems with out libgcc_s.so in base

[Diane Bruce]

On Sun, Aug 21, 2016 at 03:37:58PM +0930, Shane Ambler wrote:
> On 20/08/2016 21:30, Diane Bruce wrote:
> > On Sat, Aug 20, 2016 at 03:04:44PM +0930, Shane Ambler wrote:
> >> On 19/08/2016 10:13, Steven G. Kargl wrote:
> > ...
> >> You should find that all newer copies of libgcc_s contain compatibility
> >> support for binaries that were linked to earlier versions.
> >>
> >
...
> 
> Actually the problem is going the other way. A port gets compiled and
> linked against the newer libs but at run time it finds the base system


*sigh* No.

> lib first and loads that which doesn't support the binary that is being
> run. If the gcc6 libgcc_s was always installed and found first then we
> wouldn't have this problem.

That's exactly what the -Wl,rpath=/usr/local/lib/lib is supposed to
do. 

Look at 
/usr/ports/Mk/Uses/gfortran.mk

FFLAGS+=-Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
FCFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
LDFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
-L${LOCALBASE}/lib/gcc${_GCC_VER} -B${LOCALBASE}/bin  

Any use of GCC to compile a port *SHOULD* have the same -rpath
otherwise it gets linked with our base libgcc_s which is *harmless*
99% of the time. The cases where it isn't are outlined here:
https://people.freebsd.org/~db/libgcc.txt

Your problem is cmake here.

>From blender Makefile

USES=   cmake:outsource compiler:features desktop-file-utils \
jpeg python:3.5 shebangfix

Look at this PR
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=20812

What happens is cmake strips the necessary rpath when it installs
the final binary.

This hack:
add to CMAKE_ARGS 
-DCMAKE_INSTALL_RPATH:STRING="${LOCALBASE}/lib/gcc${_GCC_VER}"

Will tell cmake to not strip the necessary gcc rpath information.
BTW I'd be interested if this fixed blender for you.

However, if this is the way to fix these problems, then it should
be documented or fixed cmake. However a naive non ports infrastructure build
using gcc/gfortran or cmake will still run into these problems.

> 
> I first found this issue trying to import numpy into blender. As blender
> had started and was using the base libgcc_s, when I tried to import
> numpy that needed the newer libgcc_s for it's fortran code it failed. I
> discovered that setting LD_LIBRARY_PATH in the environment when starting
> blender got it to load the newer libgcc_s which then worked when

Yes. Or a LD_PRELOAD (man rtld)

The stanza added in the ports infrastructure is a kludge added to
work around our out of date base libgcc_s.so


> importing numpy, so I've been happy doing that for a couple of years.

This is exactly the sort of bugs that have been reported in the ports
system for years.

> 
> I have seen the same thing were a python module has brought in the base
> libgcc_s before numpy which needed the newer one. The dynamic loading of
> python modules seems to be the only time I have seen this. Either
> changing the import order or LD_LIBRARY_PATH to get the newer lib loaded
> the first time has solved the issue.

Yep. You are SOL if your base program does not have a -rpath linking
/usr/local/lib libgcc_s first. (BTW A LD_PRELOAD will fix your
problem here as it forces the port libgcc_s to be already loaded
before rtld has to search for it. It will satisfy the linking requirements
without messing around with LD_LIBRARY_PATH) Any program that does
a dlopen then requiring a ports libgcc_s will also fail, not just
python.

> 
> So one solution could be to copy the newer libgcc_s into /lib but the
> newer library won't get added to base as it contains GPLv3 code. Maybe 
> remove /lib/libgcc_s.so to force the search for a newer version.

If you read my original post. (Did you read it?) That's exactly what
I suggest. We should rename it to libcc_s.so 

...
> -- 
> FreeBSD - the place to B...Software Developing
> 
> Shane Ambler
> 
> 

Diane Bruce (Getting tired and testy at explaining this bug 1000 times)
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Shane Ambler]

On 20/08/2016 21:30, Diane Bruce wrote:

On Sat, Aug 20, 2016 at 03:04:44PM +0930, Shane Ambler wrote:

On 19/08/2016 10:13, Steven G. Kargl wrote:

...

You should find that all newer copies of libgcc_s contain compatibility
support for binaries that were linked to earlier versions.



Indeed. And the version masquerading as a GNU libgcc_s in base
does the same thing. Two problems: our base libgcc_s only covers version up
to GCC_4.2.0 and there is a name conflict on the library name with
libgcc_s from the gnu compiler. Hence if a program links against base
libgcc_s first then requires libgfortran which itself requires support
for above GCC_4.2.0, the program fails. OR Whenever a program requires
support that is missing on the platform it is running on from our
libgcc_s, it will fail.

There are numerous PR's on this which all have the common problem
of linking with a libgcc_s that does not support > GCC_4.2.0


Actually the problem is going the other way. A port gets compiled and
linked against the newer libs but at run time it finds the base system
lib first and loads that which doesn't support the binary that is being
run. If the gcc6 libgcc_s was always installed and found first then we
wouldn't have this problem.

I first found this issue trying to import numpy into blender. As blender
had started and was using the base libgcc_s, when I tried to import
numpy that needed the newer libgcc_s for it's fortran code it failed. I
discovered that setting LD_LIBRARY_PATH in the environment when starting
blender got it to load the newer libgcc_s which then worked when
importing numpy, so I've been happy doing that for a couple of years.

I have seen the same thing were a python module has brought in the base
libgcc_s before numpy which needed the newer one. The dynamic loading of
python modules seems to be the only time I have seen this. Either
changing the import order or LD_LIBRARY_PATH to get the newer lib loaded
the first time has solved the issue.

So one solution could be to copy the newer libgcc_s into /lib but the
newer library won't get added to base as it contains GPLv3 code. Maybe 
remove /lib/libgcc_s.so to force the search for a newer version.


While bug reports have lead to other things, I think the solution might
be to configure/patch ld to get it searching paths to find the newer
version first. libgcc_s would be such a common case that we could have a
permanent ld setting in base to always find a newer libgcc_s before the
base version. I haven't been bitten enough to have looked at this.

--
FreeBSD - the place to B...Software Developing

Shane Ambler

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Konstantin Belousov]

On Fri, Aug 19, 2016 at 09:50:28PM +0200, Tijl Coosemans wrote:
> On Fri, 19 Aug 2016 10:28:14 +0300 Konstantin Belousov  
> wrote:
> > The option which would fix all this mess is:
> > 1. add rpath for gcc lib/ directory into spec file
> > and
> > 2. make ports collection use its own compiler instead of fighting with
> >the base.
> 
> That still doesn't cover all cases, e.g.:
> 
> port exec -> base lib -> libgcc_s.so.1
>   -> port lib -> recent libgcc_s.so.1
> 
> An example is:
> 
> % echo 'int main(void){}' > test.c
> % clang37 -o test test.c -lexecinfo -lgfortran -L/usr/local/lib/gcc5 
> -Wl,-rpath,/usr/local/lib/gcc5
> % ./test
> /lib/libgcc_s.so.1: version GCC_4.6.0 required by 
> /usr/local/lib/gcc5/libgfortran.so.3 not found
> 
> The base library (libexecinfo) doesn't have DT_RPATH or DT_RUNPATH so the
> only way rtld can find the right libgcc_s.so is if the executable (test)
> has DT_RPATH and no DT_RUNPATH.  Clang runs ld with --enable-new-dtags
> so the executable has DT_RUNPATH.  DT_RPATH is deprecated in the Linux
> world so there are probably more ports that use --enable-new-dtags.
> Another example seems to be Rust.

Indeed, and I rechecked the find_library() code against the latest gABI
once more.

So base libraries linked against libgcc_s are
/lib/libcxxrt.so.1
/usr/lib/libc++.so.1
/usr/lib/libexecinfo.so.1
/usr/lib/libprivatedevdctl.so.0
and only libexecinfo would be somewhat problematic.  libcxxrt and libc++
come from C++ runtime, which must be provided by the port's compiler,
the private library should not be linked to by behaving applications.

I suppose that libexecinfo pull unwinder from libgcc_s.  It might be
possible just dlopen() libgcc_s for _Unwind_Backtrace, it seems.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Diane Bruce]

On Sat, Aug 20, 2016 at 03:04:44PM +0930, Shane Ambler wrote:
> On 19/08/2016 10:13, Steven G. Kargl wrote:
...
> You should find that all newer copies of libgcc_s contain compatibility
> support for binaries that were linked to earlier versions.
> 

Indeed. And the version masquerading as a GNU libgcc_s in base
does the same thing. Two problems: our base libgcc_s only covers version up
to GCC_4.2.0 and there is a name conflict on the library name with
libgcc_s from the gnu compiler. Hence if a program links against base
libgcc_s first then requires libgfortran which itself requires support
for above GCC_4.2.0, the program fails. OR Whenever a program requires
support that is missing on the platform it is running on from our
libgcc_s, it will fail. 

There are numerous PR's on this which all have the common problem
of linking with a libgcc_s that does not support > GCC_4.2.0

Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Shane Ambler]

On 19/08/2016 10:13, Steven G. Kargl wrote:

On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote:

On Thu, 18 Aug 2016 14:48:28 +0200 Dimitry Andric  wrote:


how would you solve the problem of having
multiple, possibly incompatible versions of the same library in
different directories?

For example, on one of my systems, I now have these:

/usr/local/lib/gcc47/libgcc_s.so.1
/usr/local/lib/gcc48/libgcc_s.so.1
/usr/local/lib/gcc49/libgcc_s.so.1
/usr/local/lib/gcc5/libgcc_s.so.1
/usr/local/lib/gcc6/libgcc_s.so.1
/usr/local/lib/gcc7/libgcc_s.so.1

So which one are you going to put at the front of the path?  The gcc7
version?  If you are lucky that one is backwards compatible with all the
previous ones,


You should find that all newer copies of libgcc_s contain compatibility
support for binaries that were linked to earlier versions.

For the gcc policy on library ABI compatibility read -
http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

You can find the ABI versions contained in each library -

% strings /usr/lib/libgcc_s.so | grep 'GCC_[0-9]' | sort -u
GCC_3.0
GCC_3.3
GCC_3.3.1
GCC_3.4
GCC_3.4.2
GCC_3.4.4
GCC_4.0.0
GCC_4.2.0
GCC_4.3.0

% strings /usr/local/lib/gcc48/libgcc_s.so.1 | grep 'GCC_[0-9]' | sort -u
GCC_3.0
GCC_3.3
GCC_3.3.1
GCC_3.4
GCC_3.4.2
GCC_3.4.4
GCC_4.0.0
GCC_4.2.0
GCC_4.3.0
GCC_4.6.0
GCC_4.7.0
GCC_4.8.0


--
FreeBSD - the place to B...Software Developing

Shane Ambler

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Tijl Coosemans]

On Fri, 19 Aug 2016 10:28:14 +0300 Konstantin Belousov  
wrote:
> The option which would fix all this mess is:
> 1. add rpath for gcc lib/ directory into spec file
> and
> 2. make ports collection use its own compiler instead of fighting with
>the base.

That still doesn't cover all cases, e.g.:

port exec -> base lib -> libgcc_s.so.1
  -> port lib -> recent libgcc_s.so.1

An example is:

% echo 'int main(void){}' > test.c
% clang37 -o test test.c -lexecinfo -lgfortran -L/usr/local/lib/gcc5 
-Wl,-rpath,/usr/local/lib/gcc5
% ./test
/lib/libgcc_s.so.1: version GCC_4.6.0 required by 
/usr/local/lib/gcc5/libgfortran.so.3 not found

The base library (libexecinfo) doesn't have DT_RPATH or DT_RUNPATH so the
only way rtld can find the right libgcc_s.so is if the executable (test)
has DT_RPATH and no DT_RUNPATH.  Clang runs ld with --enable-new-dtags
so the executable has DT_RUNPATH.  DT_RPATH is deprecated in the Linux
world so there are probably more ports that use --enable-new-dtags.
Another example seems to be Rust.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Konstantin Belousov]

On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote:
> On Thu, 18 Aug 2016 14:48:28 +0200 Dimitry Andric  wrote:
> > On 18 Aug 2016, at 11:15, Tijl Coosemans  wrote: 
> >> On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl 
> >>  wrote:
> >>> % gfortran6 -o z foo.f90 && ./z
> >>> /lib/libgcc_s.so.1: version GCC_4.6.0 required by \
> >>> /usr/local/lib/gcc6/libgfortran.so.3 not found
> >>> % ldconfig -r | grep libgcc
> >>>6:-lgcc_s.1 => /lib/libgcc_s.so.1
> >>>735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1
> >>> 
> >>> Clearly, ldd is looking for 735 but finds 6.  If the lang/gcc6 could
> >>> be convinced to build, install, and use libgcc_s6.so.1, then the
> >>> problem is solved without a wrapper.  
> >> 
> >> In this case the real cause of the problem is that compilers and linkers
> >> search /lib and /usr/lib last and ldconfig searches them first.  Renaming
> >> the library is just a hack around that.  
> > 
> > Well, even if you would adjust the compilers and linkers to look in
> > /usr/local/lib first,
> 
> No, I wanted to change /etc/rc.d/ldconfig to put /lib and /usr/lib last.
> That would match base ld(1) so anything that links successfully at
> compile-time will also link successfully at run-time (if there are no
> other search order mismatches leading to conflicts).
> 
> But, this means that in case of a name conflict between base and ports,
> the ports provided library is assumed to be the right one.  I'm not 100%
> sure this is smart.  Usually the ports version of a library is more
> recent and if the name is the same it should be backward compatible, but
> if that's not the case (older or not compatible) base utilities may fail
> to run (like ./z in the example above) and that's maybe worse than ports
> or locally built programs failing.
> 
> > how would you solve the problem of having
> > multiple, possibly incompatible versions of the same library in
> > different directories?
> > 
> > For example, on one of my systems, I now have these:
> > 
> > /usr/local/lib/gcc47/libgcc_s.so.1
> > /usr/local/lib/gcc48/libgcc_s.so.1
> > /usr/local/lib/gcc49/libgcc_s.so.1
> > /usr/local/lib/gcc5/libgcc_s.so.1
> > /usr/local/lib/gcc6/libgcc_s.so.1
> > /usr/local/lib/gcc7/libgcc_s.so.1
> > 
> > So which one are you going to put at the front of the path?  The gcc7
> > version?  If you are lucky that one is backwards compatible with all the
> > previous ones, but still I would like it much better if a program
> > compiled by, say, gcc5 was linked *explicitly* against the gcc5 version
> > of libgcc_s.so.
> > 
> > Steve's proposed scheme solves that quite nicely, in my opinion.  The
> > problem is only in the details, as usual.  There will be many configure
> > scripts and libtool-like utilities out there, that assume libgcc must be
> > linked using -lgcc_s, not -lgcc_s$VERSION.
> 
> This is a separate problem that has been discussed many times before.
> The ports tree adds -Wl,-rpath to *FLAGS in several places to choose
> a library.  I now noticed there is a FAQ about this at
> https://gcc.gnu.org/faq.html#rpath.  It gives some suggestions including
> creating wrapper scripts, but they wouldn't work when code is compiled
> with gfortran but linked with Clang cc/c++.  The only thing that works
> in this case is -Wl,-rpath.  Another option would be to create a port
> that installs a recent version of libgcc in /usr/local/lib and let the
> gcc ports use that instead of their own copy.

The option which would fix all this mess is:
1. add rpath for gcc lib/ directory into spec file
and
2. make ports collection use its own compiler instead of fighting with
   the base.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Steven G. Kargl]

On Thu, Aug 18, 2016 at 05:43:04PM -0700, Steven G. Kargl wrote:
> 
> % cd ~/work/6/lib

Dang.  This should have been "cd /usr/local/lib/gcc6"

> % sed s/gcc_s/gcc_t/ < libgfortran.so.3 > zxc
> % mv zxc libgfortran.so.3 
> % elfdump -a libgfortran.so.3 | grep gcc_
> d_val: libgcc_t.so.1
> % ln -sf libgcc_s.so.1 libgcc_t.so.1

This magic can be done as a post-install step.

> % ldconfig -R
> % ldconfig -r | grep libgcc
> 6:-lgcc_s.1 => /lib/libgcc_s.so.1
> 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1
> 745:-lgcc_t.1 => /usr/local/lib/gcc6/libgcc_t.so.1
> 
> % cd tmp
> % gfortran6 -o z foo.f90 && ./z
>  Hello
> 
> That is, the name clash in ldconfig can be avoided by editing
> libgfortran.so.3 to look for a symlinked libgcc_s.so.1.
> 
> -- 
> Steve
> http://troutmask.apl.washington.edu/~kargl/

-- 
Steve
http://troutmask.apl.washington.edu/~kargl/
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Steven G. Kargl]

On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote:
> On Thu, 18 Aug 2016 14:48:28 +0200 Dimitry Andric  wrote:
>
> > how would you solve the problem of having
> > multiple, possibly incompatible versions of the same library in
> > different directories?
> > 
> > For example, on one of my systems, I now have these:
> > 
> > /usr/local/lib/gcc47/libgcc_s.so.1
> > /usr/local/lib/gcc48/libgcc_s.so.1
> > /usr/local/lib/gcc49/libgcc_s.so.1
> > /usr/local/lib/gcc5/libgcc_s.so.1
> > /usr/local/lib/gcc6/libgcc_s.so.1
> > /usr/local/lib/gcc7/libgcc_s.so.1
> > 
> > So which one are you going to put at the front of the path?  The gcc7
> > version?  If you are lucky that one is backwards compatible with all the
> > previous ones, but still I would like it much better if a program
> > compiled by, say, gcc5 was linked *explicitly* against the gcc5 version
> > of libgcc_s.so.
> > 
> > Steve's proposed scheme solves that quite nicely, in my opinion.  The
> > problem is only in the details, as usual.  There will be many configure
> > scripts and libtool-like utilities out there, that assume libgcc must be
> > linked using -lgcc_s, not -lgcc_s$VERSION.
> 
> This is a separate problem that has been discussed many times before.
> The ports tree adds -Wl,-rpath to *FLAGS in several places to choose
> a library.  I now noticed there is a FAQ about this at
> https://gcc.gnu.org/faq.html#rpath.  It gives some suggestions including
> creating wrapper scripts, but they wouldn't work when code is compiled
> with gfortran but linked with Clang cc/c++.  The only thing that works
> in this case is -Wl,-rpath.  Another option would be to create a port
> that installs a recent version of libgcc in /usr/local/lib and let the
> gcc ports use that instead of their own copy.

It gross but it appears to work:

% cd ~/work/6/lib
% sed s/gcc_s/gcc_t/ < libgfortran.so.3 > zxc
% mv zxc libgfortran.so.3 
% elfdump -a libgfortran.so.3 | grep gcc_
d_val: libgcc_t.so.1
% ln -sf libgcc_s.so.1 libgcc_t.so.1
% ldconfig -R
% ldconfig -r | grep libgcc
6:-lgcc_s.1 => /lib/libgcc_s.so.1
735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1
745:-lgcc_t.1 => /usr/local/lib/gcc6/libgcc_t.so.1

% cd tmp
% gfortran6 -o z foo.f90 && ./z
 Hello

That is, the name clash in ldconfig can be avoided by editing
libgfortran.so.3 to look for a symlinked libgcc_s.so.1.

-- 
Steve
http://troutmask.apl.washington.edu/~kargl/
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Steve Kargl]

On Thu, Aug 18, 2016 at 07:58:01PM -0400, Diane Bruce wrote:
> On Thu, Aug 18, 2016 at 04:50:49PM -0700, Steve Kargl wrote:
> > On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote:
> > > > 
> > > > For example, on one of my systems, I now have these:
> > > > 
> 
> > entry: 5
> > d_tag: DT_RPATH
> > d_val: /usr/local/lib/gcc6
> > 
> > I don't know how ELF or the ldd work, but shouldn't the DT_RPATH
> > tell ldd to look for all of the above libraries in /usr/local/lib/gcc6
> > first.  If a library isn't present, it would then look in ldconfig's
> > hints file or fallback to /lib and /usr/lib/.  But, I suppose we 
> > still run into issues as libgfortran.so.3 needs its companion libgcc_s.s.1
> > from DT_RPATH and libc.so.7 expects the one from /lib (or perhaps
> > libcxxrt.so.1?).
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120 
> 
> Anything compiled with cmake infrastructure loses the DT_RPATH.
> 

I know nothing about cmake, but it seems to be broken. :)

-- 
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Diane Bruce]

On Thu, Aug 18, 2016 at 04:50:49PM -0700, Steve Kargl wrote:
> On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote:
> > > 
> > > For example, on one of my systems, I now have these:
> > > 

> entry: 5
>   d_tag: DT_RPATH
>   d_val: /usr/local/lib/gcc6
> 
> I don't know how ELF or the ldd work, but shouldn't the DT_RPATH
> tell ldd to look for all of the above libraries in /usr/local/lib/gcc6
> first.  If a library isn't present, it would then look in ldconfig's
> hints file or fallback to /lib and /usr/lib/.  But, I suppose we 
> still run into issues as libgfortran.so.3 needs its companion libgcc_s.s.1
> from DT_RPATH and libc.so.7 expects the one from /lib (or perhaps
> libcxxrt.so.1?).


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120 

Anything compiled with cmake infrastructure loses the DT_RPATH.

> -- 
> Steve
> ___
> freebsd-toolch...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
> 

Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Steve Kargl]

On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote:
> > 
> > For example, on one of my systems, I now have these:
> > 
> > /usr/local/lib/gcc47/libgcc_s.so.1
> > /usr/local/lib/gcc48/libgcc_s.so.1
> > /usr/local/lib/gcc49/libgcc_s.so.1
> > /usr/local/lib/gcc5/libgcc_s.so.1
> > /usr/local/lib/gcc6/libgcc_s.so.1
> > /usr/local/lib/gcc7/libgcc_s.so.1
> > 
> > So which one are you going to put at the front of the path?  The gcc7
> > version?  If you are lucky that one is backwards compatible with all the
> > previous ones, but still I would like it much better if a program
> > compiled by, say, gcc5 was linked *explicitly* against the gcc5 version
> > of libgcc_s.so.
> > 
> > Steve's proposed scheme solves that quite nicely, in my opinion.  The
> > problem is only in the details, as usual.  There will be many configure
> > scripts and libtool-like utilities out there, that assume libgcc must be
> > linked using -lgcc_s, not -lgcc_s$VERSION.
> 
> I now noticed there is a FAQ about this at
> https://gcc.gnu.org/faq.html#rpath.  It gives some suggestions including
> creating wrapper scripts, but they wouldn't work when code is compiled
> with gfortran but linked with Clang cc/c++.  The only thing that works
> in this case is -Wl,-rpath.  Another option would be to create a port
> that installs a recent version of libgcc in /usr/local/lib and let the
> gcc ports use that instead of their own copy.

elfdump -a libgfortran.so.3 shows

dynamic:

entry: 0
d_tag: DT_NEEDED
d_val: libquadmath.so.0

entry: 1
d_tag: DT_NEEDED
d_val: libm.so.5

entry: 2
d_tag: DT_NEEDED
d_val: libgcc_s.so.1

entry: 3
d_tag: DT_NEEDED
d_val: libc.so.7

entry: 4
d_tag: DT_SONAME
d_val: libgfortran.so.3

entry: 5
d_tag: DT_RPATH
d_val: /usr/local/lib/gcc6

I don't know how ELF or the ldd work, but shouldn't the DT_RPATH
tell ldd to look for all of the above libraries in /usr/local/lib/gcc6
first.  If a library isn't present, it would then look in ldconfig's
hints file or fallback to /lib and /usr/lib/.  But, I suppose we 
still run into issues as libgfortran.so.3 needs its companion libgcc_s.s.1
from DT_RPATH and libc.so.7 expects the one from /lib (or perhaps
libcxxrt.so.1?).



-- 
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Tijl Coosemans]

On Thu, 18 Aug 2016 14:48:28 +0200 Dimitry Andric  wrote:
> On 18 Aug 2016, at 11:15, Tijl Coosemans  wrote: 
>> On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl 
>>  wrote:
>>> % gfortran6 -o z foo.f90 && ./z
>>> /lib/libgcc_s.so.1: version GCC_4.6.0 required by \
>>> /usr/local/lib/gcc6/libgfortran.so.3 not found
>>> % ldconfig -r | grep libgcc
>>>6:-lgcc_s.1 => /lib/libgcc_s.so.1
>>>735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1
>>> 
>>> Clearly, ldd is looking for 735 but finds 6.  If the lang/gcc6 could
>>> be convinced to build, install, and use libgcc_s6.so.1, then the
>>> problem is solved without a wrapper.  
>> 
>> In this case the real cause of the problem is that compilers and linkers
>> search /lib and /usr/lib last and ldconfig searches them first.  Renaming
>> the library is just a hack around that.  
> 
> Well, even if you would adjust the compilers and linkers to look in
> /usr/local/lib first,

No, I wanted to change /etc/rc.d/ldconfig to put /lib and /usr/lib last.
That would match base ld(1) so anything that links successfully at
compile-time will also link successfully at run-time (if there are no
other search order mismatches leading to conflicts).

But, this means that in case of a name conflict between base and ports,
the ports provided library is assumed to be the right one.  I'm not 100%
sure this is smart.  Usually the ports version of a library is more
recent and if the name is the same it should be backward compatible, but
if that's not the case (older or not compatible) base utilities may fail
to run (like ./z in the example above) and that's maybe worse than ports
or locally built programs failing.

> how would you solve the problem of having
> multiple, possibly incompatible versions of the same library in
> different directories?
> 
> For example, on one of my systems, I now have these:
> 
> /usr/local/lib/gcc47/libgcc_s.so.1
> /usr/local/lib/gcc48/libgcc_s.so.1
> /usr/local/lib/gcc49/libgcc_s.so.1
> /usr/local/lib/gcc5/libgcc_s.so.1
> /usr/local/lib/gcc6/libgcc_s.so.1
> /usr/local/lib/gcc7/libgcc_s.so.1
> 
> So which one are you going to put at the front of the path?  The gcc7
> version?  If you are lucky that one is backwards compatible with all the
> previous ones, but still I would like it much better if a program
> compiled by, say, gcc5 was linked *explicitly* against the gcc5 version
> of libgcc_s.so.
> 
> Steve's proposed scheme solves that quite nicely, in my opinion.  The
> problem is only in the details, as usual.  There will be many configure
> scripts and libtool-like utilities out there, that assume libgcc must be
> linked using -lgcc_s, not -lgcc_s$VERSION.

This is a separate problem that has been discussed many times before.
The ports tree adds -Wl,-rpath to *FLAGS in several places to choose
a library.  I now noticed there is a FAQ about this at
https://gcc.gnu.org/faq.html#rpath.  It gives some suggestions including
creating wrapper scripts, but they wouldn't work when code is compiled
with gfortran but linked with Clang cc/c++.  The only thing that works
in this case is -Wl,-rpath.  Another option would be to create a port
that installs a recent version of libgcc in /usr/local/lib and let the
gcc ports use that instead of their own copy.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Steve Kargl]

On Thu, Aug 18, 2016 at 02:48:28PM +0200, Dimitry Andric wrote:
> On 18 Aug 2016, at 11:15, Tijl Coosemans  wrote:
> > 
> > On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl 
> >  wrote:
> ...
> >> % ldconfig -r | grep libgcc
> >>6:-lgcc_s.1 => /lib/libgcc_s.so.1
> >>735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1
> >> 
> >> Clearly, ldd is looking for 735 but finds 6.  If the lang/gcc6 could
> >> be convinced to build, install, and use libgcc_s6.so.1, then the
> >> problem is solved without a wrapper.
> > 
> > In this case the real cause of the problem is that compilers and linkers
> > search /lib and /usr/lib last and ldconfig searches them first.  Renaming
> > the library is just a hack around that.
> 
> Well, even if you would adjust the compilers and linkers to look in
> /usr/local/lib first, how would you solve the problem of having
> multiple, possibly incompatible versions of the same library in
> different directories?
> 
> For example, on one of my systems, I now have these:
> 
> /usr/local/lib/gcc47/libgcc_s.so.1
> /usr/local/lib/gcc48/libgcc_s.so.1
> /usr/local/lib/gcc49/libgcc_s.so.1
> /usr/local/lib/gcc5/libgcc_s.so.1
> /usr/local/lib/gcc6/libgcc_s.so.1
> /usr/local/lib/gcc7/libgcc_s.so.1
> 
> So which one are you going to put at the front of the path?  The gcc7
> version?  If you are lucky that one is backwards compatible with all the
> previous ones, but still I would like it much better if a program
> compiled by, say, gcc5 was linked *explicitly* against the gcc5 version
> of libgcc_s.so.
> 
> Steve's proposed scheme solves that quite nicely, in my opinion.  The
> problem is only in the details, as usual.  There will be many configure
> scripts and libtool-like utilities out there, that assume libgcc must be
> linked using -lgcc_s, not -lgcc_s$VERSION.


I asked on the g...@gcc.gnu.org if there is a configure option
to go the above, and unfortunately there isn't.  I was pointed
to --enable-version-specific-runtime-libs, but was then told
that whatever it does is broken for multilib installs.

I had not considered libtool-like utilities, so Dimitry is probably
right in that this may open a can of worms.

Another hack for the ports system would be to unilaterally include
an -Wl,-rpath option on the gfortran commmand line.  Currently, 
-Wl,-rpath is added to FFLAGS, FCFLAGS, and LDFLAGS in fortran.mk.
The problem is that some ports might reset FFLAGS after fortran.mk
has been included in Makefile.   This should do the trick (watch
for cut-n-paster whitespace corruption):

Index: fortran.mk
===
--- fortran.mk  (revision 419226)
+++ fortran.mk  (working copy)
@@ -26,9 +26,8 @@
 RUN_DEPENDS+=  gfortran${_GCC_VER}:lang/gcc${_GCC_VER}
 .endif
 USE_BINUTILS=  yes
-F77=   gfortran${_GCC_VER}
-FC=gfortran${_GCC_VER}
-FFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
+F77=   gfortran${_GCC_VER} -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
+FC=gfortran${_GCC_VER} -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
 FCFLAGS+=  -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
 LDFLAGS+=  -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \
-L${LOCALBASE}/lib/gcc${_GCC_VER} -B${LOCALBASE}/bin

One potential issues may be mixed-language apps that use Fortran libraries,
but link with gcc or g++.

-- 
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Dimitry Andric]

On 18 Aug 2016, at 11:15, Tijl Coosemans  wrote:
> 
> On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl 
>  wrote:
...
>> % ldconfig -r | grep libgcc
>>6:-lgcc_s.1 => /lib/libgcc_s.so.1
>>735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1
>> 
>> Clearly, ldd is looking for 735 but finds 6.  If the lang/gcc6 could
>> be convinced to build, install, and use libgcc_s6.so.1, then the
>> problem is solved without a wrapper.
> 
> In this case the real cause of the problem is that compilers and linkers
> search /lib and /usr/lib last and ldconfig searches them first.  Renaming
> the library is just a hack around that.

Well, even if you would adjust the compilers and linkers to look in
/usr/local/lib first, how would you solve the problem of having
multiple, possibly incompatible versions of the same library in
different directories?

For example, on one of my systems, I now have these:

/usr/local/lib/gcc47/libgcc_s.so.1
/usr/local/lib/gcc48/libgcc_s.so.1
/usr/local/lib/gcc49/libgcc_s.so.1
/usr/local/lib/gcc5/libgcc_s.so.1
/usr/local/lib/gcc6/libgcc_s.so.1
/usr/local/lib/gcc7/libgcc_s.so.1

So which one are you going to put at the front of the path?  The gcc7
version?  If you are lucky that one is backwards compatible with all the
previous ones, but still I would like it much better if a program
compiled by, say, gcc5 was linked *explicitly* against the gcc5 version
of libgcc_s.so.

Steve's proposed scheme solves that quite nicely, in my opinion.  The
problem is only in the details, as usual.  There will be many configure
scripts and libtool-like utilities out there, that assume libgcc must be
linked using -lgcc_s, not -lgcc_s$VERSION.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Problems with out libgcc_s.so in base

[Tijl Coosemans]

On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl 
 wrote:
> 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 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.
> 
> I thought about this a bit, and cleaner solution might be
> to add the program suffix to libgcc_s.so.1.  For example,
> 
> % cat foo.f90
> program foo
>print *, 'Hello'
> end program
> % gfortran6 -o z foo.f90 && ./z
> /lib/libgcc_s.so.1: version GCC_4.6.0 required by \
> /usr/local/lib/gcc6/libgfortran.so.3 not found
> % ldconfig -r | grep libgcc
> 6:-lgcc_s.1 => /lib/libgcc_s.so.1
> 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1
> 
> Clearly, ldd is looking for 735 but finds 6.  If the lang/gcc6 could
> be convinced to build, install, and use libgcc_s6.so.1, then the
> problem is solved without a wrapper.

In this case the real cause of the problem is that compilers and linkers
search /lib and /usr/lib last and ldconfig searches them first.  Renaming
the library is just a hack around that.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Steve Kargl]

On Wed, Aug 17, 2016 at 06:12:51PM -0400, Diane Bruce wrote:
> On Wed, Aug 17, 2016 at 02:17:10PM -0700, Steve Kargl wrote:
> > 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 also use a wrapper:
> > > 
> > > Yes. I have also suggested we use a wrapper to the ports guys.
> > > 
> > 
> > I thought about this a bit, and cleaner solution might be
> > to add the program suffix to libgcc_s.so.1.  For example,
> > 
> > % cat foo.f90
> > program foo
> >print *, 'Hello'
> > end program
> > % gfortran6 -o z foo.f90 && ./z
> > /lib/libgcc_s.so.1: version GCC_4.6.0 required by \
> > /usr/local/lib/gcc6/libgfortran.so.3 not found
> > % ldconfig -r | grep libgcc
> > 6:-lgcc_s.1 => /lib/libgcc_s.so.1
> > 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1
> > 
> > Clearly, ldd is looking for 735 but finds 6.  If the lang/gcc6 could
> > be convinced to build, install, and use libgcc_s6.so.1, then the
> > problem is solved without a wrapper.
> 
> I like this solution. 
> 

I have asked on g...@gcc.gnu.org if it is possible to configure
gcc as above.  I know that one can bump the shared lib number,
but that won't solve the problem.

-- 
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Diane Bruce]

On Wed, Aug 17, 2016 at 02:17:10PM -0700, Steve Kargl wrote:
> 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 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.
> > 
> 
> I thought about this a bit, and cleaner solution might be
> to add the program suffix to libgcc_s.so.1.  For example,
> 
> % cat foo.f90
> program foo
>print *, 'Hello'
> end program
> % gfortran6 -o z foo.f90 && ./z
> /lib/libgcc_s.so.1: version GCC_4.6.0 required by \
> /usr/local/lib/gcc6/libgfortran.so.3 not found
> % ldconfig -r | grep libgcc
> 6:-lgcc_s.1 => /lib/libgcc_s.so.1
> 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1
> 
> Clearly, ldd is looking for 735 but finds 6.  If the lang/gcc6 could
> be convinced to build, install, and use libgcc_s6.so.1, then the
> problem is solved without a wrapper.

I like this solution. 

> 
> -- 
> Steve
> 

Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Steve Kargl]

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 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.
> 

I thought about this a bit, and cleaner solution might be
to add the program suffix to libgcc_s.so.1.  For example,

% cat foo.f90
program foo
   print *, 'Hello'
end program
% gfortran6 -o z foo.f90 && ./z
/lib/libgcc_s.so.1: version GCC_4.6.0 required by \
/usr/local/lib/gcc6/libgfortran.so.3 not found
% ldconfig -r | grep libgcc
6:-lgcc_s.1 => /lib/libgcc_s.so.1
735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1

Clearly, ldd is looking for 735 but finds 6.  If the lang/gcc6 could
be convinced to build, install, and use libgcc_s6.so.1, then the
problem is solved without a wrapper.

-- 
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Steve Kargl]

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-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Diane Bruce]

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-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Problems with out libgcc_s.so in base

[Steve Kargl]

> 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
has ever required quad floating point math. Ever.  The Fortran standard
requires REAL and DOUBLE PRECISION with the requirement that the
DP type must occupy exact twice the storage units of REAL.  Now,
the Fortran standard permits a Fortran processor to support more
than REAL and DP.  On IA32 and X86_64 hardware, gfortran happens
to support REAL(4), REAL(8), REAL(10), and REAL(16) (note I'm
using the kind type parameters of gfortran here.  The values for
the kind type parameter are not specified by a Fortran standard).
On sparc64, gfortran supports REAL(4), REaL(8), and REAL(16).

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).

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 $@

>
> 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.
>

No offense intended, but given the complete lack of work on libm
(see FreeBSD-numerics mailinglist) after I was forced to return
my commit bit, I doubt that there is anyone within the FreeBSD
community who could replace libquadmath.

-- 
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"