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

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

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

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

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

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

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

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

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

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

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

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