[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

--- Comment #34 from commit-h...@freebsd.org ---
A commit references this bug:

Author: gerald
Date: Sun May 12 19:17:10 UTC 2019
New revision: 501438
URL: https://svnweb.freebsd.org/changeset/ports/501438

Log:
  Forward port r499061 | gerald | 2019-04-15 from lang/gcc8 and gcc8-devel:

GCC has two runtime libraries:  The static library libgcc.a (-lgcc) and
the shared library libgcc_s.so (-lgcc_s).  Both implement many of the
same functions but they also each have their unique functions.  When
GCC links programs and libraries there are three possibilities:

1. gcc -static-libgcc or gcc -static: -lgcc
   => Just use libgcc.a.

2. gcc -shared-libgcc: -lgcc_s -lgcc
   => Link with libgcc_s first, so libgcc.a is only used for its unique
  functions.

3. gcc: -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed
   => Link with libgcc.a first so libgcc_s is only used for its unique
  functions (_Unwind_* functions).

Approach 3 is the default for gcc and it's also what clang and clang++ use;
approach 2 is the default for gfortran, g++ and probably other front ends.

This patch makes 3 the default for gfortran.  It significantly reduces
the use of libgcc_s.  The _Unwind_* functions are also available in the
old base system libgcc_s which means this reduces the need for
-rpath /usr/local/lib/gccN in ports that depend on libraries built with
gfortran.  Consider a dependency tree like this:

  prog -> libA -> libgcc_s (old base system libgcc_s is fine)
   -> libB -> libgcc_s (libB built with gfortran, needs new libgcc_s)

Here prog needs to be linked with -rpath /usr/local/lib/gccN even if it's
a normal C program compiled with clang.  Without -rpath it will fail to
start because it loads old libgcc_s first as a dependency of libA and then
it fails to load libB.  With this patch libB works with old base system
libgcc_s or may not need libgcc_s at all, so prog does not need to be
linked with -rpath.

  Do not bump PORTREVISION, since we'll shortly update to a newer snapshot,
  just need a consistent baseline when branching the new lang/gcc9 now that
  GCC 9.1 has been released.

  PR:   208120
  Submitted by: tijl

Changes:
  head/lang/gcc9-devel/files/patch-gfortran-libgcc

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

--- Comment #33 from commit-h...@freebsd.org ---
A commit references this bug:

Author: gerald
Date: Wed May  8 07:13:49 UTC 2019
New revision: 501002
URL: https://svnweb.freebsd.org/changeset/ports/501002

Log:
  Update to the 20180503 snapshot of GCC 8.3.1.

  On the way forward port r499061 | gerald | 2019-04-15 from lang/gcc8 [1]:

GCC has two runtime libraries:  The static library libgcc.a (-lgcc) and
the shared library libgcc_s.so (-lgcc_s).  Both implement many of the
same functions but they also each have their unique functions.  When
GCC links programs and libraries there are three possibilities:

1. gcc -static-libgcc or gcc -static: -lgcc
   => Just use libgcc.a.

2. gcc -shared-libgcc: -lgcc_s -lgcc
   => Link with libgcc_s first, so libgcc.a is only used for its unique
  functions.

3. gcc: -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed
   => Link with libgcc.a first so libgcc_s is only used for its unique
  functions (_Unwind_* functions).

Approach 3 is the default for gcc and it's also what clang and clang++ use;
approach 2 is the default for gfortran, g++ and probably other front ends.

This patch makes 3 the default for gfortran.  It significantly reduces
the use of libgcc_s.  The _Unwind_* functions are also available in the
old base system libgcc_s which means this reduces the need for
-rpath /usr/local/lib/gccN in ports that depend on libraries built with
gfortran.  Consider a dependency tree like this:

  prog -> libA -> libgcc_s (old base system libgcc_s is fine)
   -> libB -> libgcc_s (libB built with gfortran, needs new libgcc_s)

Here prog needs to be linked with -rpath /usr/local/lib/gccN even if it's
a normal C program compiled with clang.  Without -rpath it will fail to
start because it loads old libgcc_s first as a dependency of libA and then
it fails to load libB.  With this patch libB works with old base system
libgcc_s or may not need libgcc_s at all, so prog does not need to be
linked with -rpath.

  PR:   208120 [1]
  Submitted by: tijl [1]

Changes:
  head/lang/gcc8-devel/Makefile
  head/lang/gcc8-devel/distinfo
  head/lang/gcc8-devel/files/patch-gfortran-libgcc

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

--- Comment #32 from commit-h...@freebsd.org ---
A commit references this bug:

Author: gerald
Date: Sat Apr 27 14:47:53 UTC 2019
New revision: 500211
URL: https://svnweb.freebsd.org/changeset/ports/500211

Log:
  MFH: r499061
  Approved by:  portmgr (miwi)

  GCC has two runtime libraries:  The static library libgcc.a (-lgcc) and
  the shared library libgcc_s.so (-lgcc_s).  Both implement many of the
  same functions but they also each have their unique functions.  When
  GCC links programs and libraries there are three possibilities:

  1. gcc -static-libgcc or gcc -static: -lgcc
 => Just use libgcc.a.

  2. gcc -shared-libgcc: -lgcc_s -lgcc
 => Link with libgcc_s first, so libgcc.a is only used for its unique
functions.

  3. gcc: -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed
 => Link with libgcc.a first so libgcc_s is only used for its unique
functions (_Unwind_* functions).

  Approach 3 is the default for gcc and it's also what clang and clang++ use;
  approach 2 is the default for gfortran, g++ and probably other front ends.

  This patch makes 3 the default for gfortran.  It significantly reduces
  the use of libgcc_s.  The _Unwind_* functions are also available in the
  old base system libgcc_s which means this reduces the need for
  -rpath /usr/local/lib/gccN in ports that depend on libraries built with
  gfortran.  Consider a dependency tree like this:

prog -> libA -> libgcc_s (old base system libgcc_s is fine)
 -> libB -> libgcc_s (libB built with gfortran, needs new libgcc_s)

  Here prog needs to be linked with -rpath /usr/local/lib/gccN even if it's
  a normal C program compiled with clang.  Without -rpath it will fail to
  start because it loads old libgcc_s first as a dependency of libA and then
  it fails to load libB.  With this patch libB works with old base system
  libgcc_s or may not need libgcc_s at all, so prog does not need to be
  linked with -rpath.

  PR:   208120
  Submitted by: tijl

Changes:
_U  branches/2019Q2/
  branches/2019Q2/lang/gcc8/Makefile
  branches/2019Q2/lang/gcc8/files/patch-gfortran-libgcc

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

--- Comment #31 from commit-h...@freebsd.org ---
A commit references this bug:

Author: gerald
Date: Mon Apr 15 23:08:04 UTC 2019
New revision: 499061
URL: https://svnweb.freebsd.org/changeset/ports/499061

Log:
  GCC has two runtime libraries:  The static library libgcc.a (-lgcc) and
  the shared library libgcc_s.so (-lgcc_s).  Both implement many of the
  same functions but they also each have their unique functions.  When
  GCC links programs and libraries there are three possibilities:

  1. gcc -static-libgcc or gcc -static: -lgcc
 => Just use libgcc.a.

  2. gcc -shared-libgcc: -lgcc_s -lgcc
 => Link with libgcc_s first, so libgcc.a is only used for its unique
functions.

  3. gcc: -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed
 => Link with libgcc.a first so libgcc_s is only used for its unique
functions (_Unwind_* functions).

  Approach 3 is the default for gcc and it's also what clang and clang++ use;
  approach 2 is the default for gfortran, g++ and probably other front ends.

  This patch makes 3 the default for gfortran.  It significantly reduces
  the use of libgcc_s.  The _Unwind_* functions are also available in the
  old base system libgcc_s which means this reduces the need for
  -rpath /usr/local/lib/gccN in ports that depend on libraries built with
  gfortran.  Consider a dependency tree like this:

prog -> libA -> libgcc_s (old base system libgcc_s is fine)
 -> libB -> libgcc_s (libB built with gfortran, needs new libgcc_s)

  Here prog needs to be linked with -rpath /usr/local/lib/gccN even if it's
  a normal C program compiled with clang.  Without -rpath it will fail to
  start because it loads old libgcc_s first as a dependency of libA and then
  it fails to load libB.  With this patch libB works with old base system
  libgcc_s or may not need libgcc_s at all, so prog does not need to be
  linked with -rpath.

  PR:   208120
  Submitted by: tijl
  MFH:  2019Q2 (important user visible improvement)

Changes:
  head/lang/gcc8/Makefile
  head/lang/gcc8/files/patch-gfortran-libgcc

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

Diane Bruce  changed:

   What|Removed |Added

 Status|Open|Closed
 Resolution|--- |FIXED

--- Comment #30 from Diane Bruce  ---
I'm closing this as obsolete please see
https://wiki.freebsd.org/libgcc%20problem

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

--- Comment #29 from Diane Bruce  ---
(In reply to Yuri Victorovich from comment #28)

See my various notes on this subject.
https://people.freebsd.org/~db/libgcc.txt
https://people.freebsd.org/~db/libgcc_removal_proposal.log

Agreed. It's not just a cmake problem. However, it appears cmake is DTRT
although
I thought gr...@kde.org managed to duplicate my original error. There may never
have been a problem and I got it wrong. No matter. It was never intended as a
fix for the entire problem anyway. We have to as you noted again after I noted
it months ago ;) we either need a replacement libgcc that works, or a working
libquadmath that references our libgcc or a static libcc.

The static libgcc was looked at (I'll have to check my emails on this) but a
conflict was found with libunwind. (Which you have noted is a problem)

What I now believe to be happening is the following scenario. A program such as
python is compiled. In python2.7 case, there is no reference to a libgcc at all
hence no libgcc is linked. It then loads a module that *does* reference libgcc,
however it is the "wrong" libgcc. e.g. ldd -a
/usr/local/lib/libwx_gtk2u_stc-3.0.so|grep gcc
 libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80931f000)
...
Then the python program loads another module *which was* compiled against
gfortran or even gcc. e.g. openblas or atlas

 ldd /usr/local/lib/libblas.so 
/usr/local/lib/libblas.so:
libgfortran.so.3 => /usr/local/lib/gcc5/libgfortran.so.3 (0x801252000)
libm.so.5 => /lib/libm.so.5 (0x801574000)
libgcc_s.so.1 => /usr/local/lib/gcc5/libgcc_s.so.1 (0x80179f000)
libquadmath.so.0 => /usr/local/lib/gcc5/libquadmath.so.0 (0x8019b5000)
libc.so.7 => /lib/libc.so.7 (0x800823000)

and. boom. hilarity results.

One possible solution that would work in the interim for many ports is a non
gfortran version of libblas. This is the "stick head in sand" approach since
whether we like it or not, fortran is *still* something we must support
properly.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

Yuri Victorovich  changed:

   What|Removed |Added

 CC||y...@rawbw.com

--- Comment #28 from Yuri Victorovich  ---
cmake doesn't appear to be the right place for a solution, because the problem
isn't related to cmake. The core of the problem is the presence of two versions
of libgcc in the system. This can't be changed in cmake.

One of the versions needs to be eliminated. Either the base libgcc should be
deleted and some other implementation of the Unwind interface should be
adopted, or fortran's libgcc.so should be deleted, and replaced with statically
linked version if this is at all possible.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

--- Comment #27 from Michal Meloun  ---
Hmm, it seems that symbol version problem is ARM specific. 
It's introduced by this commit:
https://gcc.gnu.org/viewcvs/gcc?view=revision=128088
Unfortunately, commit log doesn't give any information why :(
In all cases, I can fix this in your base libgcc_s, so please don't take the my
previous comment into account.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

Michal Meloun  changed:

   What|Removed |Added

 CC||m...@freebsd.org

--- Comment #26 from Michal Meloun  ---
I like solution from #24, but unfortunately, libgfortran is still linked with
GCC version of libgcc_s.so. And  GCC version of libgcc_s.so exports
_Unwind_Backtrace with GCC_4.3.0 namespace/version, while base version provides
it within GCC_3.3 namespace.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

--- Comment #25 from Diane Bruce  ---

(In reply to Tijl Coosemans from comment #24)

I like this idea the best. It solves our current problem in all cases.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

--- Comment #24 from Tijl Coosemans  ---
Created attachment 179810
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=179810=edit
remove -shared-libgcc from gfortran

Here's a patch for lang/gcc that removes use of -shared-libgcc from gfortran
and libgfortan.  It means libgcc_s is only used for _Unwind_* functions which
the base system libgcc_s provides as well so use of -rpath becomes less
important.  This makes gfortran behave the same as gcc, clang and clang++.  g++
and probably also gcj still use -shared-libgcc.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

Mark Felder  changed:

   What|Removed |Added

 CC||f...@freebsd.org

--- Comment #23 from Mark Felder  ---
(In reply to groot from comment #14)

I caught someone using this libmap trick at work recently for numpy. This is
not something we should be doing in production and it will break anyway when
default gcc changes, which is now GCC 4.9 in the ports tree. I'd also like to
see the ports tree ensuring this problem does not exist.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

--- Comment #22 from Ian Lepore  ---
I see a lot of talk here about fortran and USES=fortran as some sort of fix. 
I'd just like to remind folks that this is not a fortran problem, it's a
generalized toolchain problem that has at its root our deficient libgcc_s in
base.  See comment #3 for details of how/why this isn't a fortran problem.

An actual solution, whatever that might be, will have nothing to do with
fortran per se, and will somehow fix the problem of ports finding the right
copy of the compiler support libraries for the compiler that built the port.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

--- Comment #20 from Diane Bruce  ---
In comment #19 "It doesn't matter what compiler that port is compiled with
(including clang!) so there are no (simple) hacks you can add to files under Mk
or to cmake to detect this case.  Just add USES=fortran (perhaps with a comment
that explains why)." which brings us back to part of the original problem. ;)
cmake subsystem is not truly honouring the spirit of USES=fortran as it is.
Re-read groot's comment #15

"Personally I think that the build-system should DTRT as much as possible to
deliver a working executable, and that the rpath-fix for gcc-compilers should
be added in cmake."

This suggests the proper fix would be in Modules/CheckFortranCompilerFlag.cmake
to ensure the rpath is honoured. However, it would then miss the USES_GCC flag
which also sets rpath in Mk/bsd.gcc.mk. I would suggest the fix needs to be
applied to both Mk/bsd.gcc.mk and Mk/Uses/fortran.mk

Something like the fix mentioned in comment #10 

CMAKE_ARGS+=   -DCMAKE_INSTALL_RPATH:STRING="${LOCALBASE}/lib/gcc${_GCC_VER}"

I agree with the last part of comment #19
"Because Fortran as far as I know doesn't support exceptions, patching gfortran
to remove -shared-libgcc would remove pretty much all links to libgcc_s from
Fortran libraries.  They would still link to libgfortran but there's no
libgfortran in base to cause trouble.  There could still be trouble when mixing
libraries compiled with different versions of gfortran, which may happen on
user systems when the default gcc version has been changed.  In this case it
would still be good if ports that depend on ports that have USES=fortran also
set USES=fortran."

with the caveat that we still have a problem when a program references libgcc_s
and is running with base libgcc_s then dlopen's a module which was compiled
against another libgcc_s not in base. In the case of a gfortran compiled
module, it will "want" libgfortran which will "need" a later libgcc_s version
than we currently support in base and *then* fail. ;) And as groot mentions we
still do not DTRT without the make system 'helping'. (We cannot due to the name
clash)

I discussed this in depth with a few others from toolchains on IRC. The
proposed fix I suggest is merely a stopgap until our libgcc_s can be brought up
to date. We are missing (from the gfortran viewpoint) libquadmath. We could
"lie" in our libgcc_s and it would be perfectly fine (BTW I've briefly tested
this), but the better solution is not to bump the claimed version.

e.g. readelf -a /usr/local/lib/gcc49/libgcc_s.so

Version definition section '.gnu.version_d' contains 13 entries:
  Addr: 0x1fb8  Offset: 0x001fb8  Link: 3 (.dynstr)
  00: Rev: 1  Flags: BASE   Index: 1  Cnt: 1  Name: libgcc_s.so.1
  0x001c: Rev: 1  Flags: none  Index: 2  Cnt: 1  Name: GCC_3.0
...

I don't have the final answer. All I want to do now is ensure this problem is
well documented so others know the workaround. ;)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

Tijl Coosemans  changed:

   What|Removed |Added

 CC||t...@freebsd.org

--- Comment #19 from Tijl Coosemans  ---
If an executable depends on a library (including indirect dependencies) that
needs a particular rpath then that executable should also be linked with that
rpath.  Here's an example that shows why:

program links to libA which links to (old) libgcc_s
links to libB which requires new libgcc_s

If program does not have an rpath then rtld(1) will load old libgcc_s as part
of loading libA and then fail when loading libB.

Translated to Fortran ports this becomes:

If a port installs an executable that depends on a library from another port
(including indirect dependencies) that has USES=fortran then that port should
also set USES=fortran.

It doesn't matter what compiler that port is compiled with (including clang!)
so there are no (simple) hacks you can add to files under Mk or to cmake to
detect this case.  Just add USES=fortran (perhaps with a comment that explains
why).

That said, I recently found out that gfortran, g++ and gcj call the gcc backend
with -shared-libgcc which means they link pretty much every program and library
with libgcc_s.  Clang, clang++ and gcc don't do that and instead link with
"-lgcc -Wl,--as-needed -lgcc_s  -Wl,--no-as-needed".  Because libgcc (static
library) contains all symbols from libgcc_s except _Unwind_*, libgcc_s is
almost never needed, only for code that needs stack unwinding (for instance to
throw and catch exceptions).  Because Fortran as far as I know doesn't support
exceptions, patching gfortran to remove -shared-libgcc would remove pretty much
all links to libgcc_s from Fortran libraries.  They would still link to
libgfortran but there's no libgfortran in base to cause trouble.  There could
still be trouble when mixing libraries compiled with different versions of
gfortran, which may happen on user systems when the default gcc version has
been changed.  In this case it would still be good if ports that depend on
ports that have USES=fortran also set USES=fortran.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

--- Comment #18 from Diane Bruce  ---
comment #17 good point.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

--- Comment #17 from Antoine Brodin  ---
(In reply to Diane Bruce from comment #11)
Putting this workaround in compiler.mk will not solve the issue, USE_GCC=yes or
USES=fortran don't include compiler.mk

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

--- Comment #14 from gr...@kde.org ---
Received this work-around by private email:

I think I found a work-around that fixes *runtime* dynamic linking issues. I
added the following line to /etc/libmap.conf:

libgcc_s.so.1   gcc48/libgcc_s.so.1

This seems to have solved a number of issues that I have had involving
Fortran, including numpy and scilab.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

   Priority|--- |Normal
  Flags||merge-quarterly?
 Blocks||211641


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211641
[Bug 211641] graphics/py-mayavi mayavi2 runtime error
-- 
You are receiving this mail because:
You are the assignee for the bug.

[kde-freebsd] [Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

 Blocks||204598
 CC||ko...@freebsd.org

--- Comment #13 from Kubilay Kocak  ---
Note that this issue is intended to be the one that identifies and isolates the
root cause of the symptoms, therebyte resolving all blocked issues (at the time
of writing 4)

If cmake stripping rpath turns out not to be the root cause, the summary should
be updated as more information comes to hand


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204598
[Bug 204598] math/py-matplotlib: Build failure (gcc48/libgfortran.so.3 requires
libgcc version GCC_4.6.0)
-- 
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] [Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

   Keywords||needs-qa, patch
 Status|New |Open

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] [Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

 Blocks||196862, 205294


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196862
[Bug 196862] [PATCH] x11-toolkits/py-wxPython28: Fail embedding_in_wx5.py -
gcc48/libgfortran.so.3 not found
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205294
[Bug 205294] [PATCH] x11-toolkits/py-wxPython30: Fail embedding_in_wx5.py -
gcc48/libgfortran.so.3 not found
-- 
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] [Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

 Blocks||207750
Summary|devel/cmake strips  |devel/cmake: Strips
   |necessary rpath when|necessary rpath when
   |installing any gnu compiler |installing any GNU compiler
   |from ports  |from ports


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207750
[Bug 207750] math/py-numpy: Run-time errors as it can't find
/usr/local/lib/gcc48/libgfortran.so.3
-- 
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] [Bug 208120] devel/cmake strips necessary rpath when installing any gnu compiler from ports

[bugzilla-noreply]

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

--- Comment #12 from Diane Bruce  ---
See https://people.freebsd.org/~db/libgcc_summary.txt

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] [Bug 208120] devel/cmake strips necessary rpath when installing any gnu compiler from ports

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2101
   ||99

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] [Bug 208120] devel/cmake strips necessary rpath when installing any gnu compiler from ports

[bugzilla-noreply]

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

--- Comment #11 from Diane Bruce  ---
Simpler fix to compiler.mk

Index: compiler.mk
===
--- compiler.mk (revision 416615)
+++ compiler.mk (working copy)
@@ -248,3 +248,7 @@
 .endif

 .endif
+
+.if ${CHOSEN_COMPILER_TYPE == gcc }
+CMAKE_ARGS+=   -DCMAKE_INSTALL_RPATH:STRING="${LOCALBASE}/lib/gcc${_GCC_VER}"
+.endif

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] [Bug 208120] devel/cmake strips necessary rpath when installing any gnu compiler from ports

[bugzilla-noreply]

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

--- Comment #10 from Diane Bruce  ---
Sure. My original thought was it belonged in cmake.mk anyway! groot@ convinced
me it should go in cmake port itself and myself don't care.

The pkg-message is -Wl,-rpath=%%TARGLIB%%
Which is dutifully added with USES= fortran but cmake.mk doesn't pick up
the rpath variable. That entire string is what is exposed out of the port
make subsystem and available to the port Makefile. We know at port build
time that we are using fortran hence would know to add the TARGLIB magic
but TARGLIB is not exposed.

Examining Uses fortran.mk

I note

FFLAGS+=-Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}

If _GCC_VER was available in the Makefile for the port I simply would have
added 

CMAKE_ARGS+= -DCMAKE_INSTALL_RPATH::STRING="${LOCALBASE}/lib/gcc${_GCC_VER}" 

and be done with it.

Similar could be done with GCC if set.

Thoughts?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] [Bug 208120] devel/cmake strips necessary rpath when installing any gnu compiler from ports

[bugzilla-noreply]

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

--- Comment #9 from gr...@kde.org ---
.. so far, we've mostly been talking about ports, where the infrastructure
helps with inserting the right linker flags, and comment:7 points out that it
seems to DTRT. But what about non-ports builds? Can we do something to make
CMake a helpful and useful build system on FreeBSD? Having to remember the
pkg-message from gcc48 is less convenient than having CMake itself DTRT when it
runs into gcc.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] [Bug 208120] devel/cmake strips necessary rpath when installing any gnu compiler from ports

[bugzilla-noreply]

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

--- Comment #8 from gr...@kde.org ---
(In reply to Raphael Kubo da Costa from comment #7)

> lang/gcc's pkg-message says:
> > To ensure binaries built with this toolchain find appropriate versions
> > of the necessary run-time libraries, you may want to link using
> 
> >
> >  -Wl,-rpath=/usr/local/lib/gcc48
> 
> >
> > For ports leveraging USE_GCC, USES=compiler, or USES=fortran this happens
> > transparently.

That's fine. I think the issue is more about the expectations when using a
different build system on top. In other words, what do you get with
USES=compiler and cmake as a build system inside the port? 

I would expect a port using CMake as build system and USES=fortran to link to
the right bits.

With the attached self-contained example, on 10.2 amd64, the resulting
executable does indeed link to the right libgcc_s.so, so it seems that CMake is
already doing the right thing in at least some cases.

I'll try the same thing on my BB for the ARM case next.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] [Bug 208120] devel/cmake strips necessary rpath when installing any gnu compiler from ports

[bugzilla-noreply]

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

--- Comment #7 from Raphael Kubo da Costa  ---
Created attachment 168925
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=168925=edit
Self-contained fortran+CMake example

To me, CMake does not seem to be doing anything wrong or unusual here.

lang/gcc's pkg-message says:
> To ensure binaries built with this toolchain find appropriate versions
> of the necessary run-time libraries, you may want to link using
>
>  -Wl,-rpath=/usr/local/lib/gcc48
>
> For ports leveraging USE_GCC, USES=compiler, or USES=fortran this happens
> transparently.
Indeed, if I just do `gcc48 hello.c' I get a binary that depends (via
DT_NEEDED) on libstdc++.so.6 and libgcc_so.1 (among other libraries) but with
no RPATH. And obviously I pass -Wl,rpath=/usr/local/lib/gcc48 I get a binary
that depends on those two libraries and has a DT_RPATH entry set to
/usr/local/lib/gcc48 (and ldd shows that both libstdc++.so.6 and libgcc_so.1
come from GCC 4.8's directory).

And if instead of calling `gcc48' (or `gfortran48') I create a CMakeLists.txt
and get CMake to generate a Makefile that will call the compiler, the results
are exactly the same, regardless of whether I pass
-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=YES to CMake or not.

And then if I want to use the ports tree infrastructure to call CMake for me, I
also get the same results. I'm attaching a .shar file with a test port called
"bug208120" that does exactly this (the source is based on code sent to me by
email by Ade and Diane). You can build it like a regular port, install it and
the "bug208120" binary will work just fine. It is also possible to just build
the code on your own and bypass the ports tree bits with `cd files && mkdir
build && cd build && FFLAGS=-Wl,-rpath=/usr/local/lib/gcc48 cmake .. && make
VERBOSE=1'.

> This sample network fails to compile, with gnuradio-companion failing: 
> ImportError: /lib/libgcc_s.so.1: version GCC_4.6.0 required by 
> /usr/local/lib/gcc48/libgfortran.so.3 not found
I tried looking for "gfortran48" invocations in
http://beefy4.nyi.freebsd.org/bulk/latest-per-pkg/gnuradio/3.7.8/head-amd64-default.log,
and comms/gnuradio only appears to have a USE_GCC=yes entry for FreeBSD 9.x.
It's unclear to me what is linking against libgfortran.so and how. It might be
the case that some Python library used by GNU Radio is trying to dlopen()
libgfortran, or it's actually a port that comms/gnuradio depends on that is
doing something wrong.

> This problem also affects arm and armv6.
I'm interested in hearing more about this. My knowledge about ARM and the ports
tree is zero, so please assume you're talking to a 5-year-old :-) Do you have a
link to a build log for a port that is being built incorrectly (ie. without the
right RPATH even though it is being passed to the linker)? Where/how should I
start if I wanted to investigate this and do my own tests?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] [Bug 208120] devel/cmake strips necessary rpath when installing any gnu compiler from ports

[bugzilla-noreply]

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

--- Comment #6 from Diane Bruce  ---
It also affects gcc from ports as well and not just gfortran, though the bug is
not as evident.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] [Bug 208120] devel/cmake strips necessary rpath when installing any gnu compiler from ports

[bugzilla-noreply]

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

gr...@kde.org changed:

   What|Removed |Added

 CC||gr...@kde.org

--- Comment #5 from gr...@kde.org ---
So the patch attached, which fixes up things in the fortran cmake modules,
isn't general enough. This should be done in the GNU module, or any module that
notices that it's using gcc as the backend. I can futz around with the patch in
order to make it more general.

I can use both ARM (e.g. on my Beagle Bone) and GNU Radio as test cases for
making this work, but no guarantees on a delivery date.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] [Bug 208120] devel/cmake strips necessary rpath when installing any gnu compiler from ports

[bugzilla-noreply]

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

Jeffrey Baitis  changed:

   What|Removed |Added

 CC||j...@baitis.net

--- Comment #4 from Jeffrey Baitis  ---
Created attachment 168796
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=168796=edit
Simple GNU Radio test network failure case

This sample network fails to compile, with gnuradio-companion failing:
ImportError: /lib/libgcc_s.so.1: version GCC_4.6.0 required by
/usr/local/lib/gcc48/libgfortran.so.3 not found

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] [Bug 208120] devel/cmake strips necessary rpath when installing any gnu compiler from ports

[bugzilla-noreply]

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

Koop Mast  changed:

   What|Removed |Added

   Assignee|freebsd-ports-bugs@FreeBSD. |k...@freebsd.org
   |org |
Summary|cmake strips necessary  |devel/cmake strips
   |rpath when installing any   |necessary rpath when
   |gnu compiler from ports |installing any gnu compiler
   ||from ports

--- Comment #1 from Koop Mast  ---
tweak subject, and assign to cmake maintainers.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] [Bug 208120] devel/cmake strips necessary rpath when installing any gnu compiler from ports

[bugzilla-noreply]

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

Ian Lepore  changed:

   What|Removed |Added

 CC||i...@freebsd.org

--- Comment #3 from Ian Lepore  ---
This problem also affects arm and armv6.  Ports that are built with gcc (from
ports, not the old one in base) will have references to symbols named __aeabi_*
which are compiler helper routines to implement the arm abi.  Our libgcc_s and
libc in base (both are involved, for arcane reasons) export a small subset of
the __aeabi routines, just the ones referenced by gcc 4.2.1.  I have no opinion
on how to fix it, just pointing out that trying to use the libgcc_s from base
instead of the one in $LOCALBASE that matches the gcc used to build the port is
a real problem on arm.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

[kde-freebsd] [Bug 208120] devel/cmake strips necessary rpath when installing any gnu compiler from ports

[bugzilla-noreply]

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

--- Comment #2 from Diane Bruce  ---
Uses/cmake.mk could be touched instead.


--- /usr/ports/Mk/Uses/cmake.mk 2016-03-17 15:49:04.0 -0400
+++ /usr/ports/Mk/Uses/cmake.mk.new 2016-03-13 12:36:39.0 -0400
@@ -69,7 +69,9 @@
 CMAKE_ARGS+=   -DCMAKE_C_COMPILER:STRING="${CC}" \
-DCMAKE_CXX_COMPILER:STRING="${CXX}" \
-DCMAKE_C_FLAGS:STRING="${CFLAGS}" \
+   -DCMAKE_Fortran_FLAGS_DEBUG:STRING="${FFLAGS}" \
-DCMAKE_C_FLAGS_DEBUG:STRING="${CFLAGS}" \
+   -DCMAKE_Fortran_FLAGS_RELEASE:STRING="${FFLAGS}" \
-DCMAKE_C_FLAGS_RELEASE:STRING="${CFLAGS}" \
-DCMAKE_CXX_FLAGS:STRING="${CXXFLAGS}" \
-DCMAKE_CXX_FLAGS_DEBUG:STRING="${CXXFLAGS}" \
@@ -80,7 +82,8 @@
-DCMAKE_INSTALL_PREFIX:PATH="${CMAKE_INSTALL_PREFIX}" \
-DCMAKE_BUILD_TYPE:STRING="${CMAKE_BUILD_TYPE}" \
-DTHREADS_HAVE_PTHREAD_ARG:BOOL=YES \
-   -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=YES
+   -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=YES \
+  
-DCMAKE_INSTALL_RPATH:STRING="${LOCALBASE}/lib/gcc${_GCC_VER}"

 CMAKE_INSTALL_PREFIX?= ${PREFIX}

This diff isn't quite right since it unconditionally always adds
CMAKE_INSTALL_RPATH

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information