Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
Sorry for being late to the party, but this Differential revision looks related: https://reviews.freebsd.org/D11482 ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
Hi Tijl, hi everyone,
and let me add Andreas who has been helping on the GCC side (both
ports, viz. his work on arm and powerpc, and upstream) and toolchain@!
And first of all, let me apologize. Clearly the experience both Tijl
as a contributor made, as well as the one some of our users including
some of you was not what I'd like to experience myself as a contributor
and user, nor what I want to provide to others.
There were some personal reasons, not related to Tijl or FreeBSD at all,
but that does not change a thing about those experiences, and I am truely
sorry for those and will work hard to avoid such a case in the future.
On Sun, 24 Feb 2019, Tijl Coosemans wrote:
> GCC_4.3.0 instead of GCC_3.3.0. The gcc commit that changed this
> doesn't explain why this was done, but we'll have to make the same
> change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is
> part of the ABI). This isn't a blocker for the patch.
>
> I emailed the patch to gerald on 2017-02-21. He responded in the usual
> way that he prefers patches submitted upstream and because I thought the
> patch would not be accepted upstream he proposed an alternative solution
> where gcc would always add -rpath on FreeBSD so you didn't have to
> specify it on the command line. I responded this wouldn't fix the case
> where clang was used as a linker (e.g. to combine fortran and c++ code
> in one program) and that the FAQ on the gcc website said it was a bad
> idea for other reasons. I also said upstream might accept my patch if
> it was a configure option but that the gcc configure scripts are
> complicated and I didn't know where to add it exactly. Then silence.
To move this forward, let me include an updated version of the patch
Tijl shared on 2017-02-21 (which still was in my inbox/todo list) for
consideration for our ports collection, initially for lang/gcc8 given
that this is the default in the ports collection.
(The lang/gcc* ports actually do carry local patches, e.g. for arm or
powerpc or -fuse-ld=lld, but you are right that I usually try to get
things upstream first, fixing things upstream myself when I can, or
asking for help. The problem in this specific case was/is that I'm
quite not enough into this area so cannot really assess and clearly
stalling over that was not good.)
Find patch-gfortran-libgcc attached which should simply plug into
lang/gcc8/files and lang/gcc8-devel/files.
Feedback very welcome!
GeraldGCC 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 make 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.
Upstream is unlikely accept a patch like this because libgfortran calls
some _Unwind_* functions and so always needs libgcc_s. Also because
every Fortran program and library links to libgfortran it makes sense
that option 2 above is the default. On FreeBSD where clang and GCC
compiled code can be mixed and where multiple libgcc_s may be installed,
option 3 is just a lot easier to deal with.
The bug that sparked this is PR 208120 (but note there's a lot of
misleading information in that bug. CMake is not actually doing
anything wrong.)
--- UTC
--- gcc/fortran/gfortranspec.c.orig 2015-06-26 17:47:23 UTC
+++ gcc/fortran/gfortranspec.c
@@ -404,7 +404,7 @@ For more information about these matters
}
}
-#ifdef ENABLE_SHARED_LIBGCC
+#if 0
if (library)
{
unsigned int i;
--- libgfortran/Makefile.in.orig2019-02-22 14:22:13.0 +
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Mon, Feb 25, 2019 at 1:58 AM Dima Pasechnik wrote: > > On Sun, Feb 24, 2019 at 8:09 PM Steve Kargl > wrote: > > > > On Sun, Feb 24, 2019 at 02:21:50PM +0100, Tijl Coosemans wrote: > > > On Sat, 23 Feb 2019 13:31:17 -0500 Diane Bruce wrote: > > > > On Sat, Feb 23, 2019 at 10:52:03AM +, Dima Pasechnik wrote: > > > >> On Sat, Feb 23, 2019 at 12:07 AM Steve Kargl > > > >> wrote: > > > >>> On Sat, Feb 23, 2019 at 09:19:01AM +1100, Dave Horsfall wrote: > > > On Fri, 22 Feb 2019, Tijl Coosemans wrote: > > > > If I were the lang/gcc maintainer this -rpath problem would be my > > > > number one priority. The current maintainer has never proposed > > > > any solutions and when I submit patches he always resists. I'm > > > > done wasting my time fighting him. > > > > > > I'm late to this discussion (not being a Fortran/Python user) but > > > is there any way to remove a recalcitrant maintainer? > > > >>> > > > >>> Can you explain what you mean? The maintainer of the lang/gcc > > > >>> ports is a long-time member of the GCC steering committee > > > >>> and a long-time maintainer of all gcc FreeBSD ports. There > > > >>> are very few FreeBSD users (like 3 of us) who have commit access > > > >>> to the gcc tree. Seems like a dubious idea to remove one of > > > >>> those 3. > > > >> > > > >> Given the amount of time unsuspecting and half-suspecting users wasted > > > >> on making Fortran code (often in form of a Python extension) working > > > >> on FreeBSD (e.g. I probably wasted weeks), time is high to do > > > >> something, e.g. commit the said patches---there is an agreement that > > > >> they are correct, right? > > > > > > > > Dima, gerald has always been very helpful in all my communications > > > > with him. Have you filed a PR for the fix? dropped him an email? > > > > > > > > I know we (gerald and ?? can't remember) tried a static lib change > > > > a few years ago. I believe it didn't work at the time due to missing > > > > symbols which we have since added. > > > > > > This cannot be entirely correct. I don't see what missing symbols this > > > would have been. I attached my patch to bug 208120 on 2017-02-09 and > > > you responded it was the best idea. mmel then discovered it didn't > > > entirely fix the problem on ARM where _Unwind_Backtrace has version > > > GCC_4.3.0 instead of GCC_3.3.0. The gcc commit that changed this > > > doesn't explain why this was done, but we'll have to make the same > > > change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is > > > part of the ABI). This isn't a blocker for the patch. > > > > > > I emailed the patch to gerald on 2017-02-21. He responded in the usual > > > way that he prefers patches submitted upstream and because I thought the > > > patch would not be accepted upstream he proposed an alternative solution > > > where gcc would always add -rpath on FreeBSD so you didn't have to > > > specify it on the command line. I responded this wouldn't fix the case > > > where clang was used as a linker (e.g. to combine fortran and c++ code > > > in one program) and that the FAQ on the gcc website said it was a bad > > > idea for other reasons. I also said upstream might accept my patch if > > > it was a configure option but that the gcc configure scripts are > > > complicated and I didn't know where to add it exactly. Then silence. > > > This is typical for all my conversations with him over the years so I > > > stopped caring. > > > > > > > I do find the above paragraph to be somewhat ironic. It seems > > that python importing Fortran compiled code runs into this > > problem. I have sent 3 or 4 patches to freebsd-ports@, freebsd-python, > > and created a PR to fix a conflict with the symbol sinpi (which I > > intend to add to libm), and I have been told to upstream my patch. > > The patch ought to be upstream, for your patch is quite meaningful > outside of FreeBSD ports. > > > > > > Well, I checked. I would need to create an account on a python > > site to send a 2-line patch. > > GitHub is hardly a "python site" (or rather CPython, as we talk about > - yes, you need to do a PR at their GitHub repo, which is totally > standard practice nowadays. > https://devguide.python.org/ > OK, if you need someone to do such a PR on your behalf, surely this > can be arranged. This is now https://github.com/python/cpython/pull/12027 Naturally it will take time to get through. Steve, where is your sinpi() et. al implementation, so that it can be mentioned there explicitly? Dima > > > Given that I actually don't > > program in python, that certainly seems to be an unreasonable > > request from the python maintainers. > > If I were a Python maintainer I might have pointed out to you that > IEEE-754 speaks about sinPi(), not sinpi(), and if you added > sinPi() to libm, it would have been fine without a patch. > (although this might be breaking naming taboos :-)) > > Dima > > > > > BTW, I am a gfortran maint
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Mon, Feb 25, 2019 at 01:58:01AM +, Dima Pasechnik wrote: > On Sun, Feb 24, 2019 at 8:09 PM Steve Kargl > > > Given that I actually don't > > program in python, that certainly seems to be an unreasonable > > request from the python maintainers. > > If I were a Python maintainer I might have pointed out to you that > IEEE-754 speaks about sinPi(), not sinpi(), and if you added > sinPi() to libm, it would have been fine without a patch. > (although this might be breaking naming taboos :-)) > And, I would tell you to read the 3 or 4 emails I sent to the various mailing list and the PR. TS 18661-4 I should ask for my commit bit back, and commit the sinpi patch just to spite people like you who spout off without actually looking at what people give you. -- 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 24, 2019 at 8:09 PM Steve Kargl wrote: > > On Sun, Feb 24, 2019 at 02:21:50PM +0100, Tijl Coosemans wrote: > > On Sat, 23 Feb 2019 13:31:17 -0500 Diane Bruce wrote: > > > On Sat, Feb 23, 2019 at 10:52:03AM +, Dima Pasechnik wrote: > > >> On Sat, Feb 23, 2019 at 12:07 AM Steve Kargl > > >> wrote: > > >>> On Sat, Feb 23, 2019 at 09:19:01AM +1100, Dave Horsfall wrote: > > On Fri, 22 Feb 2019, Tijl Coosemans wrote: > > > If I were the lang/gcc maintainer this -rpath problem would be my > > > number one priority. The current maintainer has never proposed > > > any solutions and when I submit patches he always resists. I'm > > > done wasting my time fighting him. > > > > I'm late to this discussion (not being a Fortran/Python user) but > > is there any way to remove a recalcitrant maintainer? > > >>> > > >>> Can you explain what you mean? The maintainer of the lang/gcc > > >>> ports is a long-time member of the GCC steering committee > > >>> and a long-time maintainer of all gcc FreeBSD ports. There > > >>> are very few FreeBSD users (like 3 of us) who have commit access > > >>> to the gcc tree. Seems like a dubious idea to remove one of > > >>> those 3. > > >> > > >> Given the amount of time unsuspecting and half-suspecting users wasted > > >> on making Fortran code (often in form of a Python extension) working > > >> on FreeBSD (e.g. I probably wasted weeks), time is high to do > > >> something, e.g. commit the said patches---there is an agreement that > > >> they are correct, right? > > > > > > Dima, gerald has always been very helpful in all my communications > > > with him. Have you filed a PR for the fix? dropped him an email? > > > > > > I know we (gerald and ?? can't remember) tried a static lib change > > > a few years ago. I believe it didn't work at the time due to missing > > > symbols which we have since added. > > > > This cannot be entirely correct. I don't see what missing symbols this > > would have been. I attached my patch to bug 208120 on 2017-02-09 and > > you responded it was the best idea. mmel then discovered it didn't > > entirely fix the problem on ARM where _Unwind_Backtrace has version > > GCC_4.3.0 instead of GCC_3.3.0. The gcc commit that changed this > > doesn't explain why this was done, but we'll have to make the same > > change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is > > part of the ABI). This isn't a blocker for the patch. > > > > I emailed the patch to gerald on 2017-02-21. He responded in the usual > > way that he prefers patches submitted upstream and because I thought the > > patch would not be accepted upstream he proposed an alternative solution > > where gcc would always add -rpath on FreeBSD so you didn't have to > > specify it on the command line. I responded this wouldn't fix the case > > where clang was used as a linker (e.g. to combine fortran and c++ code > > in one program) and that the FAQ on the gcc website said it was a bad > > idea for other reasons. I also said upstream might accept my patch if > > it was a configure option but that the gcc configure scripts are > > complicated and I didn't know where to add it exactly. Then silence. > > This is typical for all my conversations with him over the years so I > > stopped caring. > > > > I do find the above paragraph to be somewhat ironic. It seems > that python importing Fortran compiled code runs into this > problem. I have sent 3 or 4 patches to freebsd-ports@, freebsd-python, > and created a PR to fix a conflict with the symbol sinpi (which I > intend to add to libm), and I have been told to upstream my patch. The patch ought to be upstream, for your patch is quite meaningful outside of FreeBSD ports. > > Well, I checked. I would need to create an account on a python > site to send a 2-line patch. GitHub is hardly a "python site" (or rather CPython, as we talk about - yes, you need to do a PR at their GitHub repo, which is totally standard practice nowadays. https://devguide.python.org/ OK, if you need someone to do such a PR on your behalf, surely this can be arranged. > Given that I actually don't > program in python, that certainly seems to be an unreasonable > request from the python maintainers. If I were a Python maintainer I might have pointed out to you that IEEE-754 speaks about sinPi(), not sinpi(), and if you added sinPi() to libm, it would have been fine without a patch. (although this might be breaking naming taboos :-)) Dima > > BTW, I am a gfortran maintainer. gfortran is the only Fortran > compiler available for FreeBSD that actually implements most > of the Fortran standards. I've spent 15+ years making sure > gfortran works on FreeBSD and that changes to GCC don't cause > regression. This is first time I've seen your patch. AFAICT, > the file libgfortran/Makefile.am needs a patch, and then a > around of automake, autoconf, aclocal needs to be done. Just > need to figure out what needs
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 24, 2019 at 02:21:50PM +0100, Tijl Coosemans wrote: > On Sat, 23 Feb 2019 13:31:17 -0500 Diane Bruce wrote: > > On Sat, Feb 23, 2019 at 10:52:03AM +, Dima Pasechnik wrote: > >> On Sat, Feb 23, 2019 at 12:07 AM Steve Kargl > >> wrote: > >>> On Sat, Feb 23, 2019 at 09:19:01AM +1100, Dave Horsfall wrote: > On Fri, 22 Feb 2019, Tijl Coosemans wrote: > > If I were the lang/gcc maintainer this -rpath problem would be my > > number one priority. The current maintainer has never proposed > > any solutions and when I submit patches he always resists. I'm > > done wasting my time fighting him. > > I'm late to this discussion (not being a Fortran/Python user) but > is there any way to remove a recalcitrant maintainer? > >>> > >>> Can you explain what you mean? The maintainer of the lang/gcc > >>> ports is a long-time member of the GCC steering committee > >>> and a long-time maintainer of all gcc FreeBSD ports. There > >>> are very few FreeBSD users (like 3 of us) who have commit access > >>> to the gcc tree. Seems like a dubious idea to remove one of > >>> those 3. > >> > >> Given the amount of time unsuspecting and half-suspecting users wasted > >> on making Fortran code (often in form of a Python extension) working > >> on FreeBSD (e.g. I probably wasted weeks), time is high to do > >> something, e.g. commit the said patches---there is an agreement that > >> they are correct, right? > > > > Dima, gerald has always been very helpful in all my communications > > with him. Have you filed a PR for the fix? dropped him an email? > > > > I know we (gerald and ?? can't remember) tried a static lib change > > a few years ago. I believe it didn't work at the time due to missing > > symbols which we have since added. > > This cannot be entirely correct. I don't see what missing symbols this > would have been. I attached my patch to bug 208120 on 2017-02-09 and > you responded it was the best idea. mmel then discovered it didn't > entirely fix the problem on ARM where _Unwind_Backtrace has version > GCC_4.3.0 instead of GCC_3.3.0. The gcc commit that changed this > doesn't explain why this was done, but we'll have to make the same > change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is > part of the ABI). This isn't a blocker for the patch. > > I emailed the patch to gerald on 2017-02-21. He responded in the usual > way that he prefers patches submitted upstream and because I thought the > patch would not be accepted upstream he proposed an alternative solution > where gcc would always add -rpath on FreeBSD so you didn't have to > specify it on the command line. I responded this wouldn't fix the case > where clang was used as a linker (e.g. to combine fortran and c++ code > in one program) and that the FAQ on the gcc website said it was a bad > idea for other reasons. I also said upstream might accept my patch if > it was a configure option but that the gcc configure scripts are > complicated and I didn't know where to add it exactly. Then silence. > This is typical for all my conversations with him over the years so I > stopped caring. > I do find the above paragraph to be somewhat ironic. It seems that python importing Fortran compiled code runs into this problem. I have sent 3 or 4 patches to freebsd-ports@, freebsd-python, and created a PR to fix a conflict with the symbol sinpi (which I intend to add to libm), and I have been told to upstream my patch. Well, I checked. I would need to create an account on a python site to send a 2-line patch. Given that I actually don't program in python, that certainly seems to be an unreasonable request from the python maintainers. BTW, I am a gfortran maintainer. gfortran is the only Fortran compiler available for FreeBSD that actually implements most of the Fortran standards. I've spent 15+ years making sure gfortran works on FreeBSD and that changes to GCC don't cause regression. This is first time I've seen your patch. AFAICT, the file libgfortran/Makefile.am needs a patch, and then a around of automake, autoconf, aclocal needs to be done. Just need to figure out what needs to change and ensure that it does not break the rest of the computing world. -- 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sat, 23 Feb 2019 13:31:17 -0500 Diane Bruce wrote: > On Sat, Feb 23, 2019 at 10:52:03AM +, Dima Pasechnik wrote: >> On Sat, Feb 23, 2019 at 12:07 AM Steve Kargl >> wrote: >>> On Sat, Feb 23, 2019 at 09:19:01AM +1100, Dave Horsfall wrote: On Fri, 22 Feb 2019, Tijl Coosemans wrote: > If I were the lang/gcc maintainer this -rpath problem would be my > number one priority. The current maintainer has never proposed > any solutions and when I submit patches he always resists. I'm > done wasting my time fighting him. I'm late to this discussion (not being a Fortran/Python user) but is there any way to remove a recalcitrant maintainer? >>> >>> Can you explain what you mean? The maintainer of the lang/gcc >>> ports is a long-time member of the GCC steering committee >>> and a long-time maintainer of all gcc FreeBSD ports. There >>> are very few FreeBSD users (like 3 of us) who have commit access >>> to the gcc tree. Seems like a dubious idea to remove one of >>> those 3. >> >> Given the amount of time unsuspecting and half-suspecting users wasted >> on making Fortran code (often in form of a Python extension) working >> on FreeBSD (e.g. I probably wasted weeks), time is high to do >> something, e.g. commit the said patches---there is an agreement that >> they are correct, right? > > Dima, gerald has always been very helpful in all my communications > with him. Have you filed a PR for the fix? dropped him an email? > > I know we (gerald and ?? can't remember) tried a static lib change > a few years ago. I believe it didn't work at the time due to missing > symbols which we have since added. This cannot be entirely correct. I don't see what missing symbols this would have been. I attached my patch to bug 208120 on 2017-02-09 and you responded it was the best idea. mmel then discovered it didn't entirely fix the problem on ARM where _Unwind_Backtrace has version GCC_4.3.0 instead of GCC_3.3.0. The gcc commit that changed this doesn't explain why this was done, but we'll have to make the same change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is part of the ABI). This isn't a blocker for the patch. I emailed the patch to gerald on 2017-02-21. He responded in the usual way that he prefers patches submitted upstream and because I thought the patch would not be accepted upstream he proposed an alternative solution where gcc would always add -rpath on FreeBSD so you didn't have to specify it on the command line. I responded this wouldn't fix the case where clang was used as a linker (e.g. to combine fortran and c++ code in one program) and that the FAQ on the gcc website said it was a bad idea for other reasons. I also said upstream might accept my patch if it was a configure option but that the gcc configure scripts are complicated and I didn't know where to add it exactly. Then silence. This is typical for all my conversations with him over the years so I stopped caring. I'm not asking that he stops maintaining gcc. All I want is a little more pragmatism. User experience is more important than the patch being in the perfect shape to be submitted upstream. Be more practical instead of idealistic. The -rpath problem affects all users. Maintaining a patch in the ports tree affects just the maintainer. Make decisions based on weighing pros and cons. Ideals are just guidelines. If a situation is bad enough then committing an imperfect patch is better than doing nothing. I'm a user of gcc on FreeBSD. I'm not a gcc developer and I don't want to become one. If a maintainer wants patches to be in a perfect shape he's asking users to be developers. This doesn't work. Either the maintainer has to improve the patch himself or he has to play the role of liaison between the user and an upstream developer. If this takes too long and the situation is bad enough then he has to be willing to add the imperfect patch to the port. ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sat, Feb 23, 2019 at 6:31 PM Diane Bruce wrote: [...] > Dima, gerald has always been very helpful in all my communications> with him. > > Have you filed a PR for the fix? dropped him an email? Diane, well, after reading many threads on this issue I stumbled upon https://forums.freebsd.org/threads/freebsd-11-2-libgcc_s-so-1-error.67031/ ---it advises to add to /etc/libmap.conf the line libgcc_s.so.1 /usr/local/lib/gccX/libgcc_s.so.1 ---where X to be replaced with the major gfortran version one uses. By the way, is this anywhere in the current documentation? These kinds of things seem to be documented for FreeBSD 7.3, cf. https://docs.freebsd.org/doc/7.3-RELEASE/usr/share/doc/en/articles/custom-gcc/configuring-ports-gcc.html but then everything that needs this hack was supposed to be resolved? Naturally, this is ugly and should not be needed, and nothing like this is needed on Linux (or Solaris). As what I do on FreeBSD is porting a largish Python library (basically, an update to the current Sagemath version (8.6) what's inhttps://www.freshports.org/math/sage/, but the 1st goal would be more modest, just an ability to build and run in the "user space", not as a FreeBSD port), these kinds of workarounds aren't really feasible, as long as "finished product" is concerned. In fact, I started working on this on FreeBSD 11, where the math library was lacking standard symbols for a number of complex functions, and stopped, as I felt it's just too much of a hassle to work around, and picked it up again after in FreeBSD 12 this has been resolved (Steve (kargl) played a major role in it, I gather). > > I know we (gerald and ?? can't remember) tried a static lib change > a few years ago. I believe it didn't work at the time due to missing > symbols which we have since added. I am trying to understand what the situation is. If everything that is needed for this fix is already there, then what's precluding it from going forward? I've also looked at using flang instead of gfortran (it's great that FreeBSD has it available), but it seems to come with its own set of issues... Thanks, Dima http://users.ox.ac.uk/~coml0531/ ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sat, Feb 23, 2019 at 10:52:03AM +, Dima Pasechnik wrote: > On Sat, Feb 23, 2019 at 12:07 AM Steve Kargl > wrote: > > > > On Sat, Feb 23, 2019 at 09:19:01AM +1100, Dave Horsfall wrote: > > > On Fri, 22 Feb 2019, Tijl Coosemans wrote: > > > > > > > If I were the lang/gcc maintainer this -rpath problem would be my number > > > > one priority. The current maintainer has never proposed any solutions > > > > and when I submit patches he always resists. I'm done wasting my time > > > > fighting him. > > > > > > I'm late to this discussion (not being a Fortran/Python user) but is there > > > any way to remove a recalcitrant maintainer? > > > > > > > Dave, > > > > Can you explain what you mean? The maintainer of the lang/gcc > > ports is a long-time member of the GCC steering committee > > and a long-time maintainer of all gcc FreeBSD ports. There > > are very few FreeBSD users (like 3 of us) who have commit access > > to the gcc tree. Seems like a dubious idea to remove one of > > those 3. > > Given the amount of time unsuspecting and half-suspecting users wasted > on making Fortran code (often in form of a Python extension) working > on FreeBSD (e.g. I probably wasted weeks), time is high to do > something, e.g. commit the said patches---there is an agreement that > they are correct, right? > > Dima > http://users.ox.ac.uk/~coml0531/ Dima, gerald has always been very helpful in all my communications with him. Have you filed a PR for the fix? dropped him an email? I know we (gerald and ?? can't remember) tried a static lib change a few years ago. I believe it didn't work at the time due to missing symbols which we have since added. > > > > > -- > > Steve Diane -- - d...@freebsd.org d...@db.net http://artemis.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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sat, Feb 23, 2019 at 12:07 AM Steve Kargl wrote: > > On Sat, Feb 23, 2019 at 09:19:01AM +1100, Dave Horsfall wrote: > > On Fri, 22 Feb 2019, Tijl Coosemans wrote: > > > > > If I were the lang/gcc maintainer this -rpath problem would be my number > > > one priority. The current maintainer has never proposed any solutions > > > and when I submit patches he always resists. I'm done wasting my time > > > fighting him. > > > > I'm late to this discussion (not being a Fortran/Python user) but is there > > any way to remove a recalcitrant maintainer? > > > > Dave, > > Can you explain what you mean? The maintainer of the lang/gcc > ports is a long-time member of the GCC steering committee > and a long-time maintainer of all gcc FreeBSD ports. There > are very few FreeBSD users (like 3 of us) who have commit access > to the gcc tree. Seems like a dubious idea to remove one of > those 3. Given the amount of time unsuspecting and half-suspecting users wasted on making Fortran code (often in form of a Python extension) working on FreeBSD (e.g. I probably wasted weeks), time is high to do something, e.g. commit the said patches---there is an agreement that they are correct, right? Dima http://users.ox.ac.uk/~coml0531/ > > -- > 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" ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sat, Feb 23, 2019 at 09:19:01AM +1100, Dave Horsfall wrote: > On Fri, 22 Feb 2019, Tijl Coosemans wrote: > > > If I were the lang/gcc maintainer this -rpath problem would be my number > > one priority. The current maintainer has never proposed any solutions > > and when I submit patches he always resists. I'm done wasting my time > > fighting him. > > I'm late to this discussion (not being a Fortran/Python user) but is there > any way to remove a recalcitrant maintainer? > Dave, Can you explain what you mean? The maintainer of the lang/gcc ports is a long-time member of the GCC steering committee and a long-time maintainer of all gcc FreeBSD ports. There are very few FreeBSD users (like 3 of us) who have commit access to the gcc tree. Seems like a dubious idea to remove one of those 3. -- 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, 22 Feb 2019, Tijl Coosemans wrote: If I were the lang/gcc maintainer this -rpath problem would be my number one priority. The current maintainer has never proposed any solutions and when I submit patches he always resists. I'm done wasting my time fighting him. I'm late to this discussion (not being a Fortran/Python user) but is there any way to remove a recalcitrant maintainer? -- Dave ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, 22 Feb 2019 19:14:33 +0200 Konstantin Belousov wrote: > On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote: >> 1) GCC can add new symbols or new versions of them with every release >> which means the problem can reappear with every new GCC release and GCC >> releases aren't aligned with FreeBSD releases. > Right, this is known and accepted ABI changes. We must cope with them > if we intend to run newer gcc and newer gcc' compiled binaries. > >> 2) Base system libgcc is essentially libcompilerrt, the LLVM compiler >> runtime. LLVM doesn't seem to need these symbols, nothing in base needs >> these symbols so why should we implement these third party compiler >> runtime helper functions? > Because we strive to provide a usable system, not locked to one compiler. > IMO we must support both gcc and clang and their compilation results, > each with some version variance, regardless of the compiler used for > the base system. > >> 3) With my gfortran patch you don't need to implement anything. It's an >> apply-once-and-stop-worrying-about-it solution for all versions of FreeBSD. > Because all missed symbols are resolved from the compiler's libgcc.a before > linker insert a reference to libgcc_s.so.1, or due to some other cause ? Yes, for clang/clang++/gcc if you compile with -### you'll see this: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" => only code that uses stack unwinding uses libgcc_s For gfortran/g++ you'll see this: -lgcc_s -lgcc => almost all code uses libgcc_s gcc/g++/gfortran also accept -shared-libgcc and -static-libgcc command line arguments but nobody uses these. clang/clang++ does not seem to support them. -shared-libgcc: -lgcc_s -lgcc => almost all code uses libgcc_s -static-libgcc: -lgcc => nothing uses libgcc_s libgcc.a: contains compiler runtime functions. I don't really consider these part of the ABI. libgcc_s.so: contains most of the functions of libgcc.a and also _Unwind* functions which are part of the ABI. clang/clang++ will never use the compiler runtime functions in libgcc_s.so because it always links with libgcc.a first. gcc/g++/gfortran link with -L/usr/local/lib/gcc* internally so at compile time they always use their own libgcc.a and libgcc_s.so. If you apply my ldconfig patch it will list gcc libgcc_s.so before the base system libgcc_s.so so you don't have to patch gfortran. If you apply my gfortran patch it will only need libgcc_s.so for stack unwinding which our libgcc_s.so handles just fine so you don't need the ldconfig patch (although it still helps to sort multiple versions of other gcc runtime libraries). Either way, our libgcc_s.so only needs to provide _Unwind* and nothing else. This doesn't lock FreeBSD to one compiler. It may be useful to add __float128 functions to our libgcc.a to enable clang __float128 support. I haven't looked into 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, Feb 22, 2019 at 10:27:30AM -0800, Steve Kargl wrote: > Then the assertion that nothing in base needs libgcc_s.so is wrong? > > And, yes, if an application is currently using /lib/libgcc_s.so, > then it would need to be recompiled. When it is recompiled, it > can use libcompiler_rt or, if need be, it can use the libgcc_s.so > provided by a gcc port. This is the other name for 'breaking the ABI'. ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, Feb 22, 2019 at 07:09:11PM +0200, Konstantin Belousov wrote: > On Fri, Feb 22, 2019 at 08:44:54AM -0800, Steve Kargl wrote: > > > > Because FreeBSD usurped the name of a well-known library from a > > well-known open source project. Users might expect that that > > well-known library has the same ABI and functionality of the > > library provided by the well-known project. > Nothing was usurped, you can lower your tone. > > Initially libgcc_s.so.1 was provided by gcc and the library was updated > during the regular gcc imports. When gcc changed the license, the > libgcc_s.so.1 become stalled due to the block on the import of the new > gcc versions. I know the history. When FreeBSD decided to move away from gcc, then it should move away. That includes either removing libgcc_s.so or renaming it. As it is now, FreeBSD libgcc_s.so does not provide the ABI in the official libgcc_s.so as distributed with any version of gcc newer than gcc=4.5.z. It clearly is causing problems. Yes, I know some oddball architectures cannot (or at least could not) be compiled with clang/llvm, so contrib/gcc remains in the tree. In these special cases, then libgcc_s.so can be installed as part of installing contrib/gcc. > Some parts of gcc-provided libgcc_s.so.1 were replaced with llvm unwinder, > some parts with compiler-rt functions. The new functions added by gcc > were not imported because nobody who can do that knew about the problem. > Generic hand-waving is not the problem description. > > Now, that the list of missing symbols is collected and possible sources > for them are identified, at least some gaps can be filled. > > > > > If nothing in base needs /lib/libgcc_s, then let's remove it. > > If nothing in base needs it, let's rename name it to libfreebsd_s.so. > This cannot be done, because it breaks the base system ABI. In > particular, after that almost all compiled C++ apps will be broken, and > significant amount of threaded programs as well. Then the assertion that nothing in base needs libgcc_s.so is wrong? And, yes, if an application is currently using /lib/libgcc_s.so, then it would need to be recompiled. When it is recompiled, it can use libcompiler_rt or, if need be, it can use the libgcc_s.so provided by a gcc port. -- 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, 22 Feb 2019 08:44:54 -0800 Steve Kargl wrote: > On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote: >> On Fri, 22 Feb 2019 15:39:17 +0200 Konstantin Belousov >>> Do you agree that the ultimate and proper solution is to add missed symbols >>> and versions to the base libgcc_s.so.1 ? IMO it is, and this thread started >>> to show some work which might finally solve that. >>> (But about as-needed for libgfortran see above). >> >> Not really no: >> >> 1) GCC can add new symbols or new versions of them with every release >> which means the problem can reappear with every new GCC release and GCC >> releases aren't aligned with FreeBSD releases. > > GCC developers do add new symbols. Not sure what you mean by > new versions. The ABI is stable. If they change the ABI, then > they would bump the major number to 2. The symbol versions like GCC_4.6.0. The library uses symbol versioning so they can add new versions of the same symbol without removing the old versions. This way adding new versions of a symbol doesn't change the ABI. >> 2) Base system libgcc is essentially libcompilerrt, the LLVM compiler >> runtime. LLVM doesn't seem to need these symbols, nothing in base needs >> these symbols so why should we implement these third party compiler >> runtime helper functions? > > Because FreeBSD usurped the name of a well-known library from a > well-known open source project. Users might expect that that > well-known library has the same ABI and functionality of the > library provided by the well-known project. > > If nothing in base needs /lib/libgcc_s, then let's remove it. > If nothing in base needs it, let's rename name it to libfreebsd_s.so. Clang uses the name libgcc_s so clang compiled code can throw exceptions to gcc compiled code and vice versa. I suspect that FreeBSD libgcc_s only needs to provide the _Unwind* symbols and nothing else. Then it could be renamed to libunwind or something and then gcc could be patched so its libgcc_s no longer provides _Unwind* and instead links to the FreeBSD libunwind. Then clang also needs to be patched to use libunwind instead of libgcc_s. It's just easier to keep using the name libgcc_s. It was perhaps a mistake of the GCC developers to put compiler runtime functions, which are compiler specific, and stack unwinding, which is part of the system ABI that is common to all compilers, in one library. >> 3) With my gfortran patch you don't need to implement anything. It's an >> apply-once-and-stop-worrying-about-it solution for all versions of FreeBSD. > > Your patching a gfortran spec file. Don't you need to worry > about the spec file changing, which may invalidate your patch? Yes, I'll give you that one. The patch has to be kept up-to-date, but that's trivial compared to making FreeBSD erratas when a new gcc release adds a new function to libgcc. ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote: > On Fri, 22 Feb 2019 15:39:17 +0200 Konstantin Belousov > wrote: > > Yes, we absolutely must avoid situation where two similar libraries > > (i.e. providing some subset of symbols from other) are linked into the > > same executing process. > > > > I think your patches would be a definitive improvement, esp. the part > > which makes libgfortran linking only as needed. > > > > For the other part, which makes the ports dso a priority over the base > > dso, I would exercise some more causion. For ports we know only about > > libgcc_s.so.1 which has the same name in base and in ports, other > > libraries in base should have libprivate suffix to not conflict, right ? > > What about openssl libraries ? > > As long as libraries have a different name the search order in the > ldconfig cache doesn't matter. So libfoo.so.x and libprivatefoo.so.x > don't conflict but neither do libfoo.so.x and libfoo.so.y. Some > libraries in base have the libprivate prefix and they are not meant to > be used by ports at all. The openssl libraries in base have a different > version suffix than security/openssl* and are allowed to be used by > ports. > > > I think such setup makes it easier for user to accidentaly break the system. > > She could install something manually (not from ports), or copy some file > > into /usr/local/lib, which conflicts with base and cause troubles. > > Or they could copy something in /lib or /usr/lib and break their system. > > The idea behind the ldconfig patch is that the runtime search order > should be as close as possible to a typical compile time order. > Typically compilers and linkers search /usr/local before /usr, so > ldconfig should search /usr/local before /usr. Anyone that wants a > different order needs to provide a good explanation for that and I don't > think protecting users from shooting themselves in the foot is a good > enough reason. > > Similarly, I think our default PATH is also backwards. Major Linux > distros and MacOS all put /usr/local/bin before /usr/bin. > > # User can override sysadmin who can override OS: > PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin > > > Do you agree that the ultimate and proper solution is to add missed symbols > > and versions to the base libgcc_s.so.1 ? IMO it is, and this thread started > > to show some work which might finally solve that. > > (But about as-needed for libgfortran see above). > > Not really no: > > 1) GCC can add new symbols or new versions of them with every release > which means the problem can reappear with every new GCC release and GCC > releases aren't aligned with FreeBSD releases. Right, this is known and accepted ABI changes. We must cope with them if we intend to run newer gcc and newer gcc' compiled binaries. > 2) Base system libgcc is essentially libcompilerrt, the LLVM compiler > runtime. LLVM doesn't seem to need these symbols, nothing in base needs > these symbols so why should we implement these third party compiler > runtime helper functions? Because we strive to provide a usable system, not locked to one compiler. IMO we must support both gcc and clang and their compilation results, each with some version variance, regardless of the compiler used for the base system. > 3) With my gfortran patch you don't need to implement anything. It's an > apply-once-and-stop-worrying-about-it solution for all versions of FreeBSD. Because all missed symbols are resolved from the compiler's libgcc.a before linker insert a reference to libgcc_s.so.1, or due to some other cause ? ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, Feb 22, 2019 at 08:44:54AM -0800, Steve Kargl wrote: > On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote: > > On Fri, 22 Feb 2019 15:39:17 +0200 Konstantin Belousov > > wrote: > > > Yes, we absolutely must avoid situation where two similar libraries > > > (i.e. providing some subset of symbols from other) are linked into the > > > same executing process. > > > > > > I think your patches would be a definitive improvement, esp. the part > > > which makes libgfortran linking only as needed. > > > > > > For the other part, which makes the ports dso a priority over the base > > > dso, I would exercise some more causion. For ports we know only about > > > libgcc_s.so.1 which has the same name in base and in ports, other > > > libraries in base should have libprivate suffix to not conflict, right ? > > > What about openssl libraries ? > > > > As long as libraries have a different name the search order in the > > ldconfig cache doesn't matter. So libfoo.so.x and libprivatefoo.so.x > > don't conflict but neither do libfoo.so.x and libfoo.so.y. Some > > libraries in base have the libprivate prefix and they are not meant to > > be used by ports at all. The openssl libraries in base have a different > > version suffix than security/openssl* and are allowed to be used by > > ports. > > > > > I think such setup makes it easier for user to accidentaly break the > > > system. > > > She could install something manually (not from ports), or copy some file > > > into /usr/local/lib, which conflicts with base and cause troubles. > > > > Or they could copy something in /lib or /usr/lib and break their system. > > > > The idea behind the ldconfig patch is that the runtime search order > > should be as close as possible to a typical compile time order. > > Typically compilers and linkers search /usr/local before /usr, so > > ldconfig should search /usr/local before /usr. Anyone that wants a > > different order needs to provide a good explanation for that and I don't > > think protecting users from shooting themselves in the foot is a good > > enough reason. > > > > Similarly, I think our default PATH is also backwards. Major Linux > > distros and MacOS all put /usr/local/bin before /usr/bin. > > > > # User can override sysadmin who can override OS: > > PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin > > > > > Do you agree that the ultimate and proper solution is to add missed > > > symbols > > > and versions to the base libgcc_s.so.1 ? IMO it is, and this thread > > > started > > > to show some work which might finally solve that. > > > (But about as-needed for libgfortran see above). > > > > Not really no: > > > > 1) GCC can add new symbols or new versions of them with every release > > which means the problem can reappear with every new GCC release and GCC > > releases aren't aligned with FreeBSD releases. > > GCC developers do add new symbols. Not sure what you mean by > new versions. The ABI is stable. If they change the ABI, then > they would bump the major number to 2. They add new symbols and provide new symbol versions where these symbols are assigned. > > > 2) Base system libgcc is essentially libcompilerrt, the LLVM compiler > > runtime. LLVM doesn't seem to need these symbols, nothing in base needs > > these symbols so why should we implement these third party compiler > > runtime helper functions? > > Because FreeBSD usurped the name of a well-known library from a > well-known open source project. Users might expect that that > well-known library has the same ABI and functionality of the > library provided by the well-known project. Nothing was usurped, you can lower your tone. Initially libgcc_s.so.1 was provided by gcc and the library was updated during the regular gcc imports. When gcc changed the license, the libgcc_s.so.1 become stalled due to the block on the import of the new gcc versions. Some parts of gcc-provided libgcc_s.so.1 were replaced with llvm unwinder, some parts with compiler-rt functions. The new functions added by gcc were not imported because nobody who can do that knew about the problem. Generic hand-waving is not the problem description. Now, that the list of missing symbols is collected and possible sources for them are identified, at least some gaps can be filled. > > If nothing in base needs /lib/libgcc_s, then let's remove it. > If nothing in base needs it, let's rename name it to libfreebsd_s.so. This cannot be done, because it breaks the base system ABI. In particular, after that almost all compiled C++ apps will be broken, and significant amount of threaded programs as well. > > > 3) With my gfortran patch you don't need to implement anything. It's an > > apply-once-and-stop-worrying-about-it solution for all versions of FreeBSD. > > Your patching a gfortran spec file. Don't you need to worry > about the spec file changing, which may invalidate your patch? > > -- > Steve ___ freebsd-po
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, Feb 22, 2019 at 05:11:20PM +0100, Tijl Coosemans wrote: > On Thu, 21 Feb 2019 10:24:51 -0800 Steve Kargl > > > BTW, if you compare gcc trunks symbol map > > ./x86_64-unknown-freebsd13.0/libgcc/libgcc.map > > with src/lib/libgcc_s/Version.map, you'll find that > > that maps are no one-to-one. > > Yes, libgcc_s implements stack unwinding and exception handling and > libgcc.a does not. The stack unwinding and exception handling code has > to be shared so all code in a process uses the same implementation and > accompanying data structures. The above map files are for libgcc_s.so. Yes, the name for the in-tree map file for libgcc_s.so is libgcc.map. -- 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote: > On Fri, 22 Feb 2019 15:39:17 +0200 Konstantin Belousov > wrote: > > Yes, we absolutely must avoid situation where two similar libraries > > (i.e. providing some subset of symbols from other) are linked into the > > same executing process. > > > > I think your patches would be a definitive improvement, esp. the part > > which makes libgfortran linking only as needed. > > > > For the other part, which makes the ports dso a priority over the base > > dso, I would exercise some more causion. For ports we know only about > > libgcc_s.so.1 which has the same name in base and in ports, other > > libraries in base should have libprivate suffix to not conflict, right ? > > What about openssl libraries ? > > As long as libraries have a different name the search order in the > ldconfig cache doesn't matter. So libfoo.so.x and libprivatefoo.so.x > don't conflict but neither do libfoo.so.x and libfoo.so.y. Some > libraries in base have the libprivate prefix and they are not meant to > be used by ports at all. The openssl libraries in base have a different > version suffix than security/openssl* and are allowed to be used by > ports. > > > I think such setup makes it easier for user to accidentaly break the system. > > She could install something manually (not from ports), or copy some file > > into /usr/local/lib, which conflicts with base and cause troubles. > > Or they could copy something in /lib or /usr/lib and break their system. > > The idea behind the ldconfig patch is that the runtime search order > should be as close as possible to a typical compile time order. > Typically compilers and linkers search /usr/local before /usr, so > ldconfig should search /usr/local before /usr. Anyone that wants a > different order needs to provide a good explanation for that and I don't > think protecting users from shooting themselves in the foot is a good > enough reason. > > Similarly, I think our default PATH is also backwards. Major Linux > distros and MacOS all put /usr/local/bin before /usr/bin. > > # User can override sysadmin who can override OS: > PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin > > > Do you agree that the ultimate and proper solution is to add missed symbols > > and versions to the base libgcc_s.so.1 ? IMO it is, and this thread started > > to show some work which might finally solve that. > > (But about as-needed for libgfortran see above). > > Not really no: > > 1) GCC can add new symbols or new versions of them with every release > which means the problem can reappear with every new GCC release and GCC > releases aren't aligned with FreeBSD releases. GCC developers do add new symbols. Not sure what you mean by new versions. The ABI is stable. If they change the ABI, then they would bump the major number to 2. > 2) Base system libgcc is essentially libcompilerrt, the LLVM compiler > runtime. LLVM doesn't seem to need these symbols, nothing in base needs > these symbols so why should we implement these third party compiler > runtime helper functions? Because FreeBSD usurped the name of a well-known library from a well-known open source project. Users might expect that that well-known library has the same ABI and functionality of the library provided by the well-known project. If nothing in base needs /lib/libgcc_s, then let's remove it. If nothing in base needs it, let's rename name it to libfreebsd_s.so. > 3) With my gfortran patch you don't need to implement anything. It's an > apply-once-and-stop-worrying-about-it solution for all versions of FreeBSD. Your patching a gfortran spec file. Don't you need to worry about the spec file changing, which may invalidate your patch? -- 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, 22 Feb 2019 09:19:54 -0700 "Russell L. Carter" wrote: > On 2/22/19 6:04 AM, Tijl Coosemans wrote: >> As for Linux, note that in theory the same problem also exists there. >> It's just that most Linux distribution only provide one version of gcc. > > Maybe some distros, but at least for debian-testing, I can install any > combo of clang-[678], gcc/g++-[678], and gfortran-[78] I see. It looks like they make all these compilers use libgcc from gcc8. ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On 2/22/19 6:04 AM, Tijl Coosemans wrote: People like Steve Kargl and me are... puzzled at why FreeBSD would do this to itself. Having people writing and running custom opensource software on a performant opensource OS is **good**. We should be enabling them. If I were the lang/gcc maintainer this -rpath problem would be my number one priority. The current maintainer has never proposed any solutions and when I submit patches he always resists. I'm done wasting my time fighting him. Then threads like this appear every few months. It's always the same people that respond with the same wrong ideas and wrong solutions and never providing patches. I always politely point out what's wrong with their ideas and provide patches that do work. Then they respond with the same wrong ideas without even trying my patches. You can see that in this very thread. Rinse, repeat. It's a people problem, not a technical problem. My patches solve the technical problem. I can't help it if people don't pick up the patches. First, thank you for your efforts! I'm not blaming anyone, simply pointing out what this situation looks like for the poor saps trying to get stuff done. I'm completely agnostic about how to solve the problem, but right now the process is: Average skill user (but technical expert on orthogonal knowledge) bringing over the sort of codes described here: https://computation.llnl.gov/projects/spack-hpc-package-manager Happily spends a bunch of time getting everything built, tries to run, libgcc_s problem. Asks on the mailing lists, gets involved in a long simmering finger pointing situation, with various solutions suggested, all of which are additional maintenance issues for the user over time. That's assuming the average user is going to want to patch ports, the base OS, or maintain root configuration files. [Like just about everyone active here I don't have a problem doing this, but just about every single scientific code practitioner I've known for the last 30 years would say, no thanks.] As for Linux, note that in theory the same problem also exists there. It's just that most Linux distribution only provide one version of gcc. Maybe some distros, but at least for debian-testing, I can install any combo of clang-[678], gcc/g++-[678], and gfortran-[78] Tools like spack and nix are pretty far down the path of effectively managing the resulting combinatorial maintenance problem nowadays. Best regards, Russell I can only recommend that you try the patches. Your Fortran/Python pipeline will just work like it does on Linux. I've attached them once more for your convenience. ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, 21 Feb 2019 10:24:51 -0800 Steve Kargl wrote: > On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote: >> There's also the fact that gfortran behaves differently from the C >> compilers (both clang and gcc) when it comes to libgcc_s. Gfortran >> always links with libgcc_s. The C compilers link with libgcc.a first >> and then with libgcc_s only as needed. > > libgfortran is gfortran's runtime library. libgcc.a is gcc's > runtime library. The link orders are the same: libgfortran > then libgcc_s; libgcc then libgcc_s No, libgcc is the runtime library for the entire compiler collection not just the C compiler. The order of libgcc.a and libgcc_s.so can be changed with -static-libgcc and -shared-libgcc: For the C compiler: default: libgcc.a -Wl,--as-needed libgcc_s.so -Wl,--no-as-needed -static-libgcc: libgcc.a -shared-libgcc: libgcc_s.so libgcc.a For gfortran: default: libgcc_s.so libgcc.a (like -shared-libgcc) -static-libgcc: libgcc.a -shared-libgcc: libgcc_s.so libgcc.a What my patch does is change the gfortran default into the C compiler default. >> This eliminates almost all >> links with libgcc_s. The only ones left are for exception handling >> and stack unwinding and gcc libgcc_s and base system libgcc_s are >> version compatible for that so it doesn't matter which one gets picked >> up. The attached patch for lang/gcc8 makes gfortran behave just like >> the C compilers. > > Just add -static to FFLAGS. Yep, you're building static > libraries. > >> We cannot rename the base system libgcc_s to libclang_s because then a >> process could load both gcc libgcc_s and base system libclang_s and I >> think that could break exception handling and stack unwinding in weird >> ways. > > Wouldn't that be a bug in the program that loads both? Perhaps yes, but it's same as with missing -rpath. We don't want to have to fix those bugs and we don't want users be confronted with them. > BTW, if you compare gcc trunks symbol map > ./x86_64-unknown-freebsd13.0/libgcc/libgcc.map > with src/lib/libgcc_s/Version.map, you'll find that > that maps are no one-to-one. Yes, libgcc_s implements stack unwinding and exception handling and libgcc.a does not. The stack unwinding and exception handling code has to be shared so all code in a process uses the same implementation and accompanying data structures. ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, 22 Feb 2019 15:39:17 +0200 Konstantin Belousov wrote: > Yes, we absolutely must avoid situation where two similar libraries > (i.e. providing some subset of symbols from other) are linked into the > same executing process. > > I think your patches would be a definitive improvement, esp. the part > which makes libgfortran linking only as needed. > > For the other part, which makes the ports dso a priority over the base > dso, I would exercise some more causion. For ports we know only about > libgcc_s.so.1 which has the same name in base and in ports, other > libraries in base should have libprivate suffix to not conflict, right ? > What about openssl libraries ? As long as libraries have a different name the search order in the ldconfig cache doesn't matter. So libfoo.so.x and libprivatefoo.so.x don't conflict but neither do libfoo.so.x and libfoo.so.y. Some libraries in base have the libprivate prefix and they are not meant to be used by ports at all. The openssl libraries in base have a different version suffix than security/openssl* and are allowed to be used by ports. > I think such setup makes it easier for user to accidentaly break the system. > She could install something manually (not from ports), or copy some file > into /usr/local/lib, which conflicts with base and cause troubles. Or they could copy something in /lib or /usr/lib and break their system. The idea behind the ldconfig patch is that the runtime search order should be as close as possible to a typical compile time order. Typically compilers and linkers search /usr/local before /usr, so ldconfig should search /usr/local before /usr. Anyone that wants a different order needs to provide a good explanation for that and I don't think protecting users from shooting themselves in the foot is a good enough reason. Similarly, I think our default PATH is also backwards. Major Linux distros and MacOS all put /usr/local/bin before /usr/bin. # User can override sysadmin who can override OS: PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin > Do you agree that the ultimate and proper solution is to add missed symbols > and versions to the base libgcc_s.so.1 ? IMO it is, and this thread started > to show some work which might finally solve that. > (But about as-needed for libgfortran see above). Not really no: 1) GCC can add new symbols or new versions of them with every release which means the problem can reappear with every new GCC release and GCC releases aren't aligned with FreeBSD releases. 2) Base system libgcc is essentially libcompilerrt, the LLVM compiler runtime. LLVM doesn't seem to need these symbols, nothing in base needs these symbols so why should we implement these third party compiler runtime helper functions? 3) With my gfortran patch you don't need to implement anything. It's an apply-once-and-stop-worrying-about-it solution for all versions of FreeBSD. ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, Feb 22, 2019 at 12:28:41PM +0100, Tijl Coosemans wrote: > > PS: For the record, the GCC_4.6.0 are needed for gfortran REAL(16) > > type. > > With my patch gfortran resolves the GCC_4.6.0 symbols statically just > like the C compilers do. If the C compilers didn't do this we'd have > this libgcc_s problem all over the place. It makes perfect sense to > make gfortran do the same thing. I'm fine with your patch. -- 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, Feb 22, 2019 at 09:32:03AM -0500, Ed Maste wrote:
> On Thu, 21 Feb 2019 at 16:47, Steve Kargl
> wrote:
> >
> > The missing symbols are
> >
> > % objdump -x lib/libgfortran.so | grep GCC_4.6.0 | awk '{print $5}' | sort
>
> Thank you for collecting these.
>
> > It looks like we may be able to grab some of these from libc/softfloat:
> > getf2.c, gttf2.c, letf2.c, lttf2.c, netf2.c.
> >
> > It looks like we might be able to grab a few more from NetBSD:
> > eqtf2.c and unordtf2.c
>
> All seven of these are available in compiler-rt, I believe they just
> need to be built and added to the version map.
>
> That leaves: __addtf3 __divtf3 __floatditf __floatsitf __floatunditf
> __multf3 __subtf3
>
> compiler-rt also has these, but provided only in this case:
> #if defined(CRT_HAS_128BIT) && defined(CRT_LDBL_128BIT)
gfortran provides a REAL(16) type, which is an implementation
of IEEE 754 binary128. If the architecture has a 128-bit float
type such as sparc64, there isn't a problem. If the 128-bit
is available from the architecture such as i386, then it uses
GCC __float128 software implementation. If compiler-rt has
these functions, are they compatiable with GCC's __float128.
--
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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, 21 Feb 2019 at 16:47, Steve Kargl
wrote:
>
> The missing symbols are
>
> % objdump -x lib/libgfortran.so | grep GCC_4.6.0 | awk '{print $5}' | sort
Thank you for collecting these.
> It looks like we may be able to grab some of these from libc/softfloat:
> getf2.c, gttf2.c, letf2.c, lttf2.c, netf2.c.
>
> It looks like we might be able to grab a few more from NetBSD:
> eqtf2.c and unordtf2.c
All seven of these are available in compiler-rt, I believe they just
need to be built and added to the version map.
That leaves: __addtf3 __divtf3 __floatditf __floatsitf __floatunditf
__multf3 __subtf3
compiler-rt also has these, but provided only in this case:
#if defined(CRT_HAS_128BIT) && defined(CRT_LDBL_128BIT)
___
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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, Feb 22, 2019 at 02:04:07PM +0100, Tijl Coosemans wrote: > On Thu, 21 Feb 2019 10:53:00 -0700 "Russell L. Carter" > wrote: > > On 2/21/19 10:05 AM, Tijl Coosemans wrote: > >> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote: > >>> On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote: > So I must dig deeper. Perhaps with rpaths interacting with the system > paths? > >>> > >>> You got it. ;) > >>> Except python doesn't have an rpath which is why this keeps coming > >>> up over and over again. > >> > >> Maybe we should just add the gcc rpaths to the python ports LDFLAGS > >> without depending on gcc. Then python should use gcc libgcc_s when > >> it exists and fall back to base system libgcc_s when it doesn't. > >> > >> Maybe we should compile *all* ports with gcc rpaths without depending > >> on gcc, just like we already compile everything with -fstack-protector > >> in LDFLAGS. > > > > I would like to briefly present the perspective from a user's POV. > > There is a large world wide population of scientific custom code > > users/coders who run on linux boxes in a wide variety of > > configurations. Almost none of that code will ever have a chance of > > ending up in /usr/ports, although there is nothing technically > > challenging about almost any of it (the porting process that is). So > > anytime any of those users wants to try running their non-ported > > scientific code, a large fraction of which contains python and/or > > gfortan code, they are going to hit the libgcc_s issue. Only a few of > > those people understand rpaths as well as I do (and I'm no expert), > > because it's never been their job. They probably struggle to figure > > out what question to ask, because, "libgcc_s? WTF?, this is python!" > > In addition, oftentimes people have sometimes big pipelines of > > different programs executing. So writing a shell script wrapper > > around each and every one of those custom programs... not going to > > happen. libmap.conf(5)? Not going to happen. Linux works out of the > > box. > > > > People like Steve Kargl and me are... puzzled at why FreeBSD would > > do this to itself. Having people writing and running custom > > opensource software on a performant opensource OS is **good**. We > > should be enabling them. > > If I were the lang/gcc maintainer this -rpath problem would be my number > one priority. The current maintainer has never proposed any solutions > and when I submit patches he always resists. I'm done wasting my time > fighting him. > > Then threads like this appear every few months. It's always the same > people that respond with the same wrong ideas and wrong solutions and > never providing patches. I always politely point out what's wrong with > their ideas and provide patches that do work. Then they respond with > the same wrong ideas without even trying my patches. You can see that > in this very thread. Rinse, repeat. > > It's a people problem, not a technical problem. My patches solve the > technical problem. I can't help it if people don't pick up the patches. Yes, we absolutely must avoid situation where two similar libraries (i.e. providing some subset of symbols from other) are linked into the same executing process. I think your patches would be a definitive improvement, esp. the part which makes libgfortran linking only as needed. For the other part, which makes the ports dso a priority over the base dso, I would exercise some more causion. For ports we know only about libgcc_s.so.1 which has the same name in base and in ports, other libraries in base should have libprivate suffix to not conflict, right ? What about openssl libraries ? I think such setup makes it easier for user to accidentaly break the system. She could install something manually (not from ports), or copy some file into /usr/local/lib, which conflicts with base and cause troubles. Do you agree that the ultimate and proper solution is to add missed symbols and versions to the base libgcc_s.so.1 ? IMO it is, and this thread started to show some work which might finally solve that. (But about as-needed for libgfortran see above). > > As for Linux, note that in theory the same problem also exists there. > It's just that most Linux distribution only provide one version of gcc. > FreeBSD provides multiple versions of multiple compilers and we allow > code compiled with different compilers to be linked together. Still, > with my patches it should all just work without -rpath. > > I can only recommend that you try the patches. Your Fortran/Python > pipeline will just work like it does on Linux. I've attached them once > more for your convenience. > Index: libexec/rc/rc.conf > === > --- libexec/rc/rc.conf(revision 343935) > +++ libexec/rc/rc.conf(working copy) > @@ -636,14 +636,14 @@ linux_enable="NO" # Linux binary compatibility > loaded > clea
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, 21 Feb 2019 10:53:00 -0700 "Russell L. Carter"
wrote:
> On 2/21/19 10:05 AM, Tijl Coosemans wrote:
>> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote:
>>> On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote:
So I must dig deeper. Perhaps with rpaths interacting with the system
paths?
>>>
>>> You got it. ;)
>>> Except python doesn't have an rpath which is why this keeps coming
>>> up over and over again.
>>
>> Maybe we should just add the gcc rpaths to the python ports LDFLAGS
>> without depending on gcc. Then python should use gcc libgcc_s when
>> it exists and fall back to base system libgcc_s when it doesn't.
>>
>> Maybe we should compile *all* ports with gcc rpaths without depending
>> on gcc, just like we already compile everything with -fstack-protector
>> in LDFLAGS.
>
> I would like to briefly present the perspective from a user's POV.
> There is a large world wide population of scientific custom code
> users/coders who run on linux boxes in a wide variety of
> configurations. Almost none of that code will ever have a chance of
> ending up in /usr/ports, although there is nothing technically
> challenging about almost any of it (the porting process that is). So
> anytime any of those users wants to try running their non-ported
> scientific code, a large fraction of which contains python and/or
> gfortan code, they are going to hit the libgcc_s issue. Only a few of
> those people understand rpaths as well as I do (and I'm no expert),
> because it's never been their job. They probably struggle to figure
> out what question to ask, because, "libgcc_s? WTF?, this is python!"
> In addition, oftentimes people have sometimes big pipelines of
> different programs executing. So writing a shell script wrapper
> around each and every one of those custom programs... not going to
> happen. libmap.conf(5)? Not going to happen. Linux works out of the
> box.
>
> People like Steve Kargl and me are... puzzled at why FreeBSD would
> do this to itself. Having people writing and running custom
> opensource software on a performant opensource OS is **good**. We
> should be enabling them.
If I were the lang/gcc maintainer this -rpath problem would be my number
one priority. The current maintainer has never proposed any solutions
and when I submit patches he always resists. I'm done wasting my time
fighting him.
Then threads like this appear every few months. It's always the same
people that respond with the same wrong ideas and wrong solutions and
never providing patches. I always politely point out what's wrong with
their ideas and provide patches that do work. Then they respond with
the same wrong ideas without even trying my patches. You can see that
in this very thread. Rinse, repeat.
It's a people problem, not a technical problem. My patches solve the
technical problem. I can't help it if people don't pick up the patches.
As for Linux, note that in theory the same problem also exists there.
It's just that most Linux distribution only provide one version of gcc.
FreeBSD provides multiple versions of multiple compilers and we allow
code compiled with different compilers to be linked together. Still,
with my patches it should all just work without -rpath.
I can only recommend that you try the patches. Your Fortran/Python
pipeline will just work like it does on Linux. I've attached them once
more for your convenience.
Index: libexec/rc/rc.conf
===
--- libexec/rc/rc.conf (revision 343935)
+++ libexec/rc/rc.conf (working copy)
@@ -636,14 +636,14 @@ linux_enable="NO" # Linux binary compatibility loaded
clear_tmp_enable="NO" # Clear /tmp at startup.
clear_tmp_X="YES" # Clear and recreate X11-related directories in /tmp
ldconfig_insecure="NO" # Set to YES to disable ldconfig security checks
-ldconfig_paths="/usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg"
+ldconfig_paths="/usr/local/lib /usr/local/lib/compat/pkg /usr/lib /usr/lib/compat /lib"
# shared library search paths
ldconfig32_paths="/usr/lib32 /usr/lib32/compat"
# 32-bit compatibility shared library search paths
-ldconfigsoft_paths="/usr/libsoft /usr/libsoft/compat /usr/local/libsoft"
+ldconfigsoft_paths="/usr/local/libsoft /usr/libsoft /usr/libsoft/compat"
# soft float compatibility shared library search paths
# Note: temporarily with extra stuff for transition
-ldconfig_paths_aout="/usr/lib/compat/aout /usr/local/lib/aout"
+ldconfig_paths_aout="/usr/local/lib/aout /usr/lib/aout /usr/lib/compat/aout"
# a.out shared library search paths
ldconfig_local_dirs="/usr/local/libdata/ldconfig"
# Local directories with ldconfig configuration files.
Index: libexec/rc/rc.d/ldconfig
===
--- libexec/rc/rc.d/ldconfig (revision 343935)
+++ libexec/rc/rc.d/ldconfig (working copy)
@@ -17,22 +17,23 @@ stop_cmd=":"
ldconfig_start()
{
- loca
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, 21 Feb 2019 16:13:15 -0800 Steve Kargl wrote: > On Thu, Feb 21, 2019 at 11:18:50PM +0100, Tijl Coosemans wrote: >> On Thu, 21 Feb 2019 13:30:41 -0500 Diane Bruce wrote: >>> On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote: On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote: > Except python doesn't have an rpath which is why this keeps coming > up over and over again. Maybe we should just add the gcc rpaths to the python ports LDFLAGS without depending on gcc. Then python should use gcc libgcc_s when it exists and fall back to base system libgcc_s when it doesn't. >>> >>> Right. Or just provide a shell shim to LD_PRELOAD IFF it is noticed >>> a specific port will require a fortran built binary module later. >>> Maybe we should compile *all* ports with gcc rpaths without depending on gcc, just like we already compile everything with -fstack-protector in LDFLAGS. There's also the fact that gfortran behaves differently from the C compilers (both clang and gcc) when it comes to libgcc_s. Gfortran always links with libgcc_s. The C compilers link with libgcc.a first and then with libgcc_s only as needed. This eliminates almost all >>> >>> What is really happening is gfortran links with libgfortran (surprise >>> surprise) and libgfortran has the requirement for @GCC_4.6.0 or later >>> links with libgcc_s. The only ones left are for exception handling and stack unwinding and gcc libgcc_s and base system libgcc_s are version compatible for that so it doesn't matter which one gets picked up. The attached patch for lang/gcc8 makes gfortran behave just like the C compilers. >>> >>> Something like this was tried already. I'll have to dig into >>> my old notes. >> >> With my patch libgfortran only needs GCC_4.2.0 and works with base >> libgcc_s. > > Why not bump the major version number of the port? Because that renames the library and like I said, renaming allows a process to load both versions, as your example shows. > % ~/work/x/bin/gfortran -o z hello.f90 > % ldd z > z: > libgfortran.so.5 => /usr/local/lib/gcc8/libgfortran.so.5 (0x20080) > libm.so.5 => /lib/libm.so.5 (0x200645000) > libgcc_s.so.2 => /safe/sgk/work/x/lib/libgcc_s.so.2 (0x200c58000) > libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x200e7) > libc.so.7 => /lib/libc.so.7 (0x2010b) > libz.so.6 => /lib/libz.so.6 (0x200678000) > libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x2014a1000) > % nm z | grep 4.6 > U __multf3@@GCC_4.6.0 > % ./z >2.000 > > Note, I'm playing with a test install into a ~/work/x directory. > The ldconfig still has issues with first come first served > > % ldconfig -r | grep libgcc_s > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > 806:-lgcc_s.1 => /usr/local/lib/gcc8/libgcc_s.so.1 > 880:-lgcc_s.2 => /safe/sgk/work/x/lib/libgcc_s.so.2 > % ldconfig -r | grep libgfortran > 808:-lgfortran.5 => /usr/local/lib/gcc8/libgfortran.so.5 > 876:-lgfortran.5 => /safe/sgk/work/x/lib/libgfortran.so.5 > > 6 is picked up due to libc.so. 806 is picked up due to > 808, but won't be there is major version number is > bumped. 876 is the loser of the first come first served, here; > but 808 would be the correct libgfortran point to 880 if I > had installed into /usr/local/lib/gcc8. The ldconfig order can be improved. I've attached another patch that I've been using for a long time. It changes /etc/rc.d/ldconfig so it puts /usr/lib and /lib last, just like compilers and linkers do at compile time, and as documented in rtld(1). It also sorts paths like /usr/local/lib/gcc(7|8|9|10) in reverse version order so if multiple versions are installed the most recent libgcc_s is listed first. > PS: For the record, the GCC_4.6.0 are needed for gfortran REAL(16) > type. With my patch gfortran resolves the GCC_4.6.0 symbols statically just like the C compilers do. If the C compilers didn't do this we'd have this libgcc_s problem all over the place. It makes perfect sense to make gfortran do the same thing. Index: libexec/rc/rc.conf === --- libexec/rc/rc.conf (revision 343935) +++ libexec/rc/rc.conf (working copy) @@ -636,14 +636,14 @@ linux_enable="NO" # Linux binary compatibility loaded clear_tmp_enable="NO" # Clear /tmp at startup. clear_tmp_X="YES" # Clear and recreate X11-related directories in /tmp ldconfig_insecure="NO" # Set to YES to disable ldconfig security checks -ldconfig_paths="/usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg" +ldconfig_paths="/usr/local/lib /usr/local/lib/compat/pkg /usr/lib /usr/lib/compat /lib" # shared library search paths ldconfig32_paths="/usr/lib32 /usr/lib32/compat" # 32-bit compatibility shared library search paths -ldconfigsoft_pat
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, Feb 21, 2019 at 01:46:46PM -0800, Steve Kargl wrote:
> On Thu, Feb 21, 2019 at 01:30:41PM -0500, Diane Bruce wrote:
> >
> > Yes yes and yes. It would be a right PITA. Perhaps it could be done
> > with some weak symbols but personally I think that's another hack.
> > I'll go look for whatever symbols we are missing and see if we
> > can fix our libgcc_s
> >
>
> Diane,
>
> The missing symbols are
>
> % objdump -x lib/libgfortran.so | grep GCC_4.6.0 | awk '{print $5}' | sort
>
> __addtf3@@GCC_4.6.0
> __divtf3@@GCC_4.6.0
> __eqtf2@@GCC_4.6.0
> __floatditf@@GCC_4.6.0
> __floatsitf@@GCC_4.6.0
> __floatunditf@@GCC_4.6.0
> __getf2@@GCC_4.6.0
> __gttf2@@GCC_4.6.0
> __letf2@@GCC_4.6.0
> __lttf2@@GCC_4.6.0
> __multf3@@GCC_4.6.0
> __netf2@@GCC_4.6.0
> __subtf3@@GCC_4.6.0
> __unordtf2@@GCC_4.6.0
>
> It looks like we may be able to grab some of these from libc/softfloat:
> getf2.c, gttf2.c, letf2.c, lttf2.c, netf2.c.
>
> It looks like we might be able to grab a few more from NetBSD:
> eqtf2.c and unordtf2.c
>
> --
> steve
Thank you.
Diane
--
- d...@freebsd.org d...@db.net http://artemis.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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, Feb 21, 2019 at 11:18:50PM +0100, Tijl Coosemans wrote: > On Thu, 21 Feb 2019 13:30:41 -0500 Diane Bruce wrote: > > On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote: > >> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote: > >>> Except python doesn't have an rpath which is why this keeps coming > >>> up over and over again. > >> > >> Maybe we should just add the gcc rpaths to the python ports LDFLAGS > >> without depending on gcc. Then python should use gcc libgcc_s when > >> it exists and fall back to base system libgcc_s when it doesn't. > > > > Right. Or just provide a shell shim to LD_PRELOAD IFF it is noticed > > a specific port will require a fortran built binary module later. > > > >> Maybe we should compile *all* ports with gcc rpaths without depending > >> on gcc, just like we already compile everything with -fstack-protector > >> in LDFLAGS. > >> > >> There's also the fact that gfortran behaves differently from the C > >> compilers (both clang and gcc) when it comes to libgcc_s. Gfortran > >> always links with libgcc_s. The C compilers link with libgcc.a first > >> and then with libgcc_s only as needed. This eliminates almost all > > > > What is really happening is gfortran links with libgfortran (surprise > > surprise) and libgfortran has the requirement for @GCC_4.6.0 or later > > > >> links with libgcc_s. The only ones left are for exception handling > >> and stack unwinding and gcc libgcc_s and base system libgcc_s are > >> version compatible for that so it doesn't matter which one gets picked > >> up. The attached patch for lang/gcc8 makes gfortran behave just like > >> the C compilers. > > > > Something like this was tried already. I'll have to dig into > > my old notes. > > With my patch libgfortran only needs GCC_4.2.0 and works with base > libgcc_s. Why not bump the major version number of the port? % svn diff libgcc/ Index: libgcc/config/t-slibgcc === --- libgcc/config/t-slibgcc (revision 269077) +++ libgcc/config/t-slibgcc (working copy) @@ -20,7 +20,7 @@ SHLIB_EXT = .so SHLIB_SOLINK = @shlib_base_name@.so -SHLIB_SOVERSION = 1 +SHLIB_SOVERSION = 2 SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION) SHLIB_MAP = @shlib_map_file@ SHLIB_OBJS = @shlib_objs@ Assuming the port system runs ldconfig to update the cache, one has % ~/work/x/bin/gfortran -o z hello.f90 % ldd z z: libgfortran.so.5 => /usr/local/lib/gcc8/libgfortran.so.5 (0x20080) libm.so.5 => /lib/libm.so.5 (0x200645000) libgcc_s.so.2 => /safe/sgk/work/x/lib/libgcc_s.so.2 (0x200c58000) libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x200e7) libc.so.7 => /lib/libc.so.7 (0x2010b) libz.so.6 => /lib/libz.so.6 (0x200678000) libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x2014a1000) % nm z | grep 4.6 U __multf3@@GCC_4.6.0 % ./z 2.000 Note, I'm playing with a test install into a ~/work/x directory. The ldconfig still has issues with first come first served % ldconfig -r | grep libgcc_s 6:-lgcc_s.1 => /lib/libgcc_s.so.1 806:-lgcc_s.1 => /usr/local/lib/gcc8/libgcc_s.so.1 880:-lgcc_s.2 => /safe/sgk/work/x/lib/libgcc_s.so.2 % ldconfig -r | grep libgfortran 808:-lgfortran.5 => /usr/local/lib/gcc8/libgfortran.so.5 876:-lgfortran.5 => /safe/sgk/work/x/lib/libgfortran.so.5 6 is picked up due to libc.so. 806 is picked up due to 808, but won't be there is major version number is bumped. 876 is the loser of the first come first served, here; but 808 would be the correct libgfortran point to 880 if I had installed into /usr/local/lib/gcc8. PS: For the record, the GCC_4.6.0 are needed for gfortran REAL(16) type. -- 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, 21 Feb 2019 13:30:41 -0500 Diane Bruce wrote: > On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote: >> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote: >>> Except python doesn't have an rpath which is why this keeps coming >>> up over and over again. >> >> Maybe we should just add the gcc rpaths to the python ports LDFLAGS >> without depending on gcc. Then python should use gcc libgcc_s when >> it exists and fall back to base system libgcc_s when it doesn't. > > Right. Or just provide a shell shim to LD_PRELOAD IFF it is noticed > a specific port will require a fortran built binary module later. > >> Maybe we should compile *all* ports with gcc rpaths without depending >> on gcc, just like we already compile everything with -fstack-protector >> in LDFLAGS. >> >> There's also the fact that gfortran behaves differently from the C >> compilers (both clang and gcc) when it comes to libgcc_s. Gfortran >> always links with libgcc_s. The C compilers link with libgcc.a first >> and then with libgcc_s only as needed. This eliminates almost all > > What is really happening is gfortran links with libgfortran (surprise > surprise) and libgfortran has the requirement for @GCC_4.6.0 or later > >> links with libgcc_s. The only ones left are for exception handling >> and stack unwinding and gcc libgcc_s and base system libgcc_s are >> version compatible for that so it doesn't matter which one gets picked >> up. The attached patch for lang/gcc8 makes gfortran behave just like >> the C compilers. > > Something like this was tried already. I'll have to dig into > my old notes. With my patch libgfortran only needs GCC_4.2.0 and works with base libgcc_s. ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, Feb 21, 2019 at 01:30:41PM -0500, Diane Bruce wrote:
>
> Yes yes and yes. It would be a right PITA. Perhaps it could be done
> with some weak symbols but personally I think that's another hack.
> I'll go look for whatever symbols we are missing and see if we
> can fix our libgcc_s
>
Diane,
The missing symbols are
% objdump -x lib/libgfortran.so | grep GCC_4.6.0 | awk '{print $5}' | sort
__addtf3@@GCC_4.6.0
__divtf3@@GCC_4.6.0
__eqtf2@@GCC_4.6.0
__floatditf@@GCC_4.6.0
__floatsitf@@GCC_4.6.0
__floatunditf@@GCC_4.6.0
__getf2@@GCC_4.6.0
__gttf2@@GCC_4.6.0
__letf2@@GCC_4.6.0
__lttf2@@GCC_4.6.0
__multf3@@GCC_4.6.0
__netf2@@GCC_4.6.0
__subtf3@@GCC_4.6.0
__unordtf2@@GCC_4.6.0
It looks like we may be able to grab some of these from libc/softfloat:
getf2.c, gttf2.c, letf2.c, lttf2.c, netf2.c.
It looks like we might be able to grab a few more from NetBSD:
eqtf2.c and unordtf2.c
--
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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, Feb 21, 2019 at 10:24:51AM -0800, Steve Kargl wrote:
>
> As anyone tried adding an empty sections to FreeBSD's
> libgcc_s,
>
> /*
> * Empty sections to work around FreeBSD abusing the name
> * of a well-known GCC library.
> */
> GCC_4.6.0 {
>
> } GCC_4.3.0;
>
> GCC_4.7.0 {
>
> } GCC_4.6.0;
>
> GCC_4.8.0 {
>
> } GCC_4.7.0;
>
> GCC_7.0.0 {
>
> } GCC_4.8.0;
>
Interesting. The above does put symbols into libgcc_s.so,
% objdump -x /usr/obj/usr/src/amd64.amd64/lib/libgcc_s/libgcc_s.so | more
...
1 0x01 0x04bd5c11 libgcc_s.so.1
2 0x00 0x0b792650 GCC_3.0
3 0x00 0x0b792653 GCC_3.3
4 0x00 0x09265f61 GCC_3.3.1
5 0x00 0x0b792654 GCC_3.4
6 0x00 0x09265e62 GCC_3.4.2
7 0x00 0x09265e64 GCC_3.4.4
8 0x00 0x09275a60 GCC_4.0.0
9 0x00 0x09276060 GCC_4.2.0
10 0x00 0x09275f60 GCC_4.3.0
11 0x00 0x09275460 GCC_4.6.0
12 0x00 0x09275360 GCC_4.7.0
13 0x00 0x09275260 GCC_4.8.0
14 0x00 0x092a5a60 GCC_7.0.0
whether the symbols added to GCC_4.6.0, 4.7.0, 4.8.0, and 7.0.0
are needed remains to been seen.
--
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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, Feb 21, 2019 at 10:53:00AM -0700, Russell L. Carter wrote: > On 2/21/19 10:05 AM, Tijl Coosemans wrote: > > On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote: > >> On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote: > >>> So I must dig deeper. Perhaps with rpaths interacting with the system > >>> paths? > >> > >> You got it. ;) > >> Except python doesn't have an rpath which is why this keeps coming > >> up over and over again. > > > > Maybe we should just add the gcc rpaths to the python ports LDFLAGS > > without depending on gcc. Then python should use gcc libgcc_s when > > it exists and fall back to base system libgcc_s when it doesn't. > > > > Maybe we should compile *all* ports with gcc rpaths without depending > > on gcc, just like we already compile everything with -fstack-protector > > in LDFLAGS. > > > > > I would like to briefly present the perspective from a user's POV. > There is a large world wide population of scientific custom code > users/coders who run on linux boxes in a wide variety of > configurations. Almost none of that code will ever have a chance of > ending up in /usr/ports, although there is nothing technically > challenging about almost any of it (the porting process that is). So > anytime any of those users wants to try running their non-ported > scientific code, a large fraction of which contains python and/or > gfortan code, they are going to hit the libgcc_s issue. Only a few of > those people understand rpaths as well as I do (and I'm no expert), > because it's never been their job. They probably struggle to figure > out what question to ask, because, "libgcc_s? WTF?, this is python!" > In addition, oftentimes people have sometimes big pipelines of > different programs executing. So writing a shell script wrapper > around each and every one of those custom programs... not going to > happen. libmap.conf(5)? Not going to happen. Linux works out of the > box. > > People like Steve Kargl and me are... puzzled at why FreeBSD would > do this to itself. Having people writing and running custom > opensource software on a performant opensource OS is **good**. We > should be enabling them. I'm not puzzled. I am amused! As a long time gfortran contributor and maintainer, and probably one of the few people who regularly builds and tests gfortran on FreeBSD, it is entertaining to see the emails about the issue. I particularly like the emails that suggest that this is a gfortran problem. It is not. -- 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote: > On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote: > > On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote: > >> So I must dig deeper. Perhaps with rpaths interacting with the system > >> paths? > > > > You got it. ;) > > Except python doesn't have an rpath which is why this keeps coming > > up over and over again. > > Maybe we should just add the gcc rpaths to the python ports LDFLAGS > without depending on gcc. Then python should use gcc libgcc_s when > it exists and fall back to base system libgcc_s when it doesn't. Right. Or just provide a shell shim to LD_PRELOAD IFF it is noticed a specific port will require a fortran built binary module later. > > Maybe we should compile *all* ports with gcc rpaths without depending > on gcc, just like we already compile everything with -fstack-protector > in LDFLAGS. > > There's also the fact that gfortran behaves differently from the C > compilers (both clang and gcc) when it comes to libgcc_s. Gfortran > always links with libgcc_s. The C compilers link with libgcc.a first > and then with libgcc_s only as needed. This eliminates almost all What is really happening is gfortran links with libgfortran (surprise surprise) and libgfortran has the requirement for @GCC_4.6.0 or later > links with libgcc_s. The only ones left are for exception handling > and stack unwinding and gcc libgcc_s and base system libgcc_s are > version compatible for that so it doesn't matter which one gets picked > up. The attached patch for lang/gcc8 makes gfortran behave just like > the C compilers. Something like this was tried already. I'll have to dig into my old notes. > > We cannot rename the base system libgcc_s to libclang_s because then a > process could load both gcc libgcc_s and base system libclang_s and I > think that could break exception handling and stack unwinding in weird > ways. Yes yes and yes. It would be a right PITA. Perhaps it could be done with some weak symbols but personally I think that's another hack. I'll go look for whatever symbols we are missing and see if we can fix our libgcc_s ... Diane -- - d...@freebsd.org d...@db.net http://artemis.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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote:
> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote:
> > On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote:
> >> So I must dig deeper. Perhaps with rpaths interacting with the system
> >> paths?
> >
> > You got it. ;)
> > Except python doesn't have an rpath which is why this keeps coming
> > up over and over again.
>
> Maybe we should just add the gcc rpaths to the python ports LDFLAGS
> without depending on gcc. Then python should use gcc libgcc_s when
> it exists and fall back to base system libgcc_s when it doesn't.
>
> Maybe we should compile *all* ports with gcc rpaths without depending
> on gcc, just like we already compile everything with -fstack-protector
> in LDFLAGS.
>
> There's also the fact that gfortran behaves differently from the C
> compilers (both clang and gcc) when it comes to libgcc_s. Gfortran
> always links with libgcc_s. The C compilers link with libgcc.a first
> and then with libgcc_s only as needed.
libgfortran is gfortran's runtime library. libgcc.a is gcc's
runtime library. The link orders are the same: libgfortran
then libgcc_s; libgcc then libgcc_s
> This eliminates almost all
> links with libgcc_s. The only ones left are for exception handling
> and stack unwinding and gcc libgcc_s and base system libgcc_s are
> version compatible for that so it doesn't matter which one gets picked
> up. The attached patch for lang/gcc8 makes gfortran behave just like
> the C compilers.
Just add -static to FFLAGS. Yep, you're building static
libraries.
> We cannot rename the base system libgcc_s to libclang_s because then a
> process could load both gcc libgcc_s and base system libclang_s and I
> think that could break exception handling and stack unwinding in weird
> ways.
Wouldn't that be a bug in the program that loads both?
BTW, if you compare gcc trunks symbol map
./x86_64-unknown-freebsd13.0/libgcc/libgcc.map
with src/lib/libgcc_s/Version.map, you'll find that
that maps are no one-to-one.
As anyone tried adding an empty sections to FreeBSD's
libgcc_s,
/*
* Empty sections to work around FreeBSD abusing the name
* of a well-known GCC library.
*/
GCC_4.6.0 {
} GCC_4.3.0;
GCC_4.7.0 {
} GCC_4.6.0;
GCC_4.8.0 {
} GCC_4.7.0;
GCC_7.0.0 {
} GCC_4.8.0;
--
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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On 2/21/19 10:05 AM, Tijl Coosemans wrote: On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote: On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote: So I must dig deeper. Perhaps with rpaths interacting with the system paths? You got it. ;) Except python doesn't have an rpath which is why this keeps coming up over and over again. Maybe we should just add the gcc rpaths to the python ports LDFLAGS without depending on gcc. Then python should use gcc libgcc_s when it exists and fall back to base system libgcc_s when it doesn't. Maybe we should compile *all* ports with gcc rpaths without depending on gcc, just like we already compile everything with -fstack-protector in LDFLAGS. I would like to briefly present the perspective from a user's POV. There is a large world wide population of scientific custom code users/coders who run on linux boxes in a wide variety of configurations. Almost none of that code will ever have a chance of ending up in /usr/ports, although there is nothing technically challenging about almost any of it (the porting process that is). So anytime any of those users wants to try running their non-ported scientific code, a large fraction of which contains python and/or gfortan code, they are going to hit the libgcc_s issue. Only a few of those people understand rpaths as well as I do (and I'm no expert), because it's never been their job. They probably struggle to figure out what question to ask, because, "libgcc_s? WTF?, this is python!" In addition, oftentimes people have sometimes big pipelines of different programs executing. So writing a shell script wrapper around each and every one of those custom programs... not going to happen. libmap.conf(5)? Not going to happen. Linux works out of the box. People like Steve Kargl and me are... puzzled at why FreeBSD would do this to itself. Having people writing and running custom opensource software on a performant opensource OS is **good**. We should be enabling them. Back in the day some of us injected FreeBSD into chunks of NASA and Sandia, for instance, on the strength of its networking performance. I would have been laughed out onto the street if I had said well um we have make a custom shell script wrapper for most of our programs just to get them to run, because this awesome not-linux OS is so advanced? Just my 2¢. Best regards, Russell ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote:
> On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote:
>> So I must dig deeper. Perhaps with rpaths interacting with the system
>> paths?
>
> You got it. ;)
> Except python doesn't have an rpath which is why this keeps coming
> up over and over again.
Maybe we should just add the gcc rpaths to the python ports LDFLAGS
without depending on gcc. Then python should use gcc libgcc_s when
it exists and fall back to base system libgcc_s when it doesn't.
Maybe we should compile *all* ports with gcc rpaths without depending
on gcc, just like we already compile everything with -fstack-protector
in LDFLAGS.
There's also the fact that gfortran behaves differently from the C
compilers (both clang and gcc) when it comes to libgcc_s. Gfortran
always links with libgcc_s. The C compilers link with libgcc.a first
and then with libgcc_s only as needed. This eliminates almost all
links with libgcc_s. The only ones left are for exception handling
and stack unwinding and gcc libgcc_s and base system libgcc_s are
version compatible for that so it doesn't matter which one gets picked
up. The attached patch for lang/gcc8 makes gfortran behave just like
the C compilers.
We cannot rename the base system libgcc_s to libclang_s because then a
process could load both gcc libgcc_s and base system libclang_s and I
think that could break exception handling and stack unwinding in weird
ways.
Index: lang/gcc8/files/patch-gcc_fortran_gfortranspec.c
===
--- lang/gcc8/files/patch-gcc_fortran_gfortranspec.c (nonexistent)
+++ lang/gcc8/files/patch-gcc_fortran_gfortranspec.c (working copy)
@@ -0,0 +1,11 @@
+--- gcc/fortran/gfortranspec.c.orig 2018-01-03 10:03:58 UTC
gcc/fortran/gfortranspec.c
+@@ -404,7 +404,7 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR
+ }
+ }
+
+-#ifdef ENABLE_SHARED_LIBGCC
++#if 0
+ if (library)
+ {
+ unsigned int i;
Property changes on: lang/gcc8/files/patch-gcc_fortran_gfortranspec.c
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Index: lang/gcc8/files/patch-libgfortran_Makefile.in
===
--- lang/gcc8/files/patch-libgfortran_Makefile.in (nonexistent)
+++ lang/gcc8/files/patch-libgfortran_Makefile.in (working copy)
@@ -0,0 +1,11 @@
+--- libgfortran/Makefile.in.orig 2018-07-26 09:48:58 UTC
libgfortran/Makefile.in
+@@ -625,7 +625,7 @@ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#'
+ $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
+ $(HWCAP_LDFLAGS) \
+ -lm $(extra_ldflags_libgfortran) \
+- $(version_arg) -Wc,-shared-libgcc
++ $(version_arg)
+
+ libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec $(LIBQUADLIB_DEP)
+ cafexeclib_LTLIBRARIES = libcaf_single.la
Property changes on: lang/gcc8/files/patch-libgfortran_Makefile.in
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
___
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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 17, 2019 at 10:42:03PM +0700, Eugene Grosbein wrote: > 17.02.2019 22:15, Diane Bruce wrote: > > > Basically all we need is a pre-loader script for interpreters ... > > We already have libmap.conf(5). It should be possible to work around the > problem > creating /usr/local/etc/libmap.d/python.conf with contents: > > [python2.7] > libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1 > > [python3.4] > libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1 > Sure but I'm guessing not all python ports *need* gfortran hence we shouldn't force all python coded ports to use the gfortran libgcc_s.so Moreover, the libmap would have to be updated everytime gfortran got updated which is true for the PRELOAD script but at least it would be with the port, not system wide. That's my two Canadian cents. (We don't even have pennies anymore up here ;) ) - Diane -- - d...@freebsd.org d...@db.net http://artemis.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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 17, 2019 at 08:21:00AM +0700, Eugene Grosbein wrote: > 17.02.2019 8:02, Russell L. Carter wrote: > > > Greetings, > > > > Restarting the FreeCAD 0.17 discussion on a different tangent. > > ... > > /usr/local/lib/gcc8/libgfortran.so.5 not found > > > > This is probably fatal to practical use of FreeCAD on FreeBSD. I was > > able to open most of my previous models, created on debian-testing, > > but some were fail. > > > > 2 threads, no happy ending: > > > > https://lists.freebsd.org/pipermail/freebsd-ports/2018-May/113336.html > > https://lists.freebsd.org/pipermail/freebsd-python/2016-January/009672.html > > > > Question to experienced porters, how is this best practice solved? I've just updated my wiki entry. I think the old entry was way too long so the TLDR; solution I suggest comes first https://wiki.freebsd.org/libgcc%20problem#preview The problem is simple. Python code is not linked with libgcc_s so the system 'fake' libgcc_s is preferred over the one that Fortran prefers since python doesn't 'know' about gfortran at all no RPATH is ever seen in time. Hence if a python binary module is loaded that does use libgcc_s.so it's the system libgcc_s not the one that Fortran "needs". > > I've just did "pkg install gcc8" using my FreeBSD 11.2/amd64 system and got > this: > > # ldd /usr/local/lib/gcc8/libgfortran.so.5 > /usr/local/lib/gcc8/libgfortran.so.5: > libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x80146e000) > libz.so.6 => /lib/libz.so.6 (0x8016ad000) > libm.so.5 => /lib/libm.so.5 (0x8018c5000) > libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x801af3000) > libc.so.7 => /lib/libc.so.7 (0x800823000) > > So, /usr/local/lib/gcc8/libgfortran.so.5 does not depend on /lib/libgcc_s.so.1 > but on /usr/local/lib/gcc8/libgcc_s.so.1 in normal case. > > I assume something is broken in your installation. Try removing gcc8 and > reinstalling > it using package. No, it's as I outlined above. I have a possible longer term transparent workaround I've mentioned to @emaste but it will take some trivial port changes. Basically all we need is a pre-loader script for interpreters that run into this such as python. (I suspect there have to be other interpreters that run into this.) Perhaps something like python2_gfortran or the like, all it has to do is PRELOAD or modify the library path so we get the 'right' libgcc_s.so. - Diane -- - d...@freebsd.org d...@db.net http://artemis.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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On 2/17/19 9:16 AM, Eugene Grosbein wrote: 17.02.2019 22:46, Diane Bruce wrote: We already have libmap.conf(5). It should be possible to work around the problem creating /usr/local/etc/libmap.d/python.conf with contents: [python2.7] libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1 [python3.4] libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1 Sure but I'm guessing not all python ports *need* gfortran hence we shouldn't force all python coded ports to use the gfortran libgcc_s.so libmap.conf(5) manual page documents how to restrict such mappings per-directory. One can create symlink for the interpreter and restrict the mapping for symlink only. Moreover, the libmap would have to be updated everytime gfortran got updated Not quite: libgcc_s.so.1 needs mapping for interpreter only as our port building system already creates libgfortran.so with right rpath for libgcc_s.so.1: # ldd /usr/local/lib/gcc8/libgfortran.so.5 /usr/local/lib/gcc8/libgfortran.so.5: libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x80146e000) libz.so.6 => /lib/libz.so.6 (0x8016ad000) libm.so.5 => /lib/libm.so.5 (0x8018c5000) libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x801af3000) libc.so.7 => /lib/libc.so.7 (0x800823000) Ok, back from RL. I see a lot of discussion, and am totally agnostic about what the "correct" solution is. I read Diane Bruce's page and ran the script: # DB solution # https://wiki.freebsd.org/libgcc%20problem export LD_PRELOAD=/usr/local/lib/gcc8/libgcc_s.so FreeCAD $* No libgcc_s.so.1 problems over three consecutive test all runs. 'FreeCAD' is a binary executable that runs a lot of python under the hood. That's what I needed, thank you to all. Regards, Russell ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
17.02.2019 22:46, Diane Bruce wrote: >> We already have libmap.conf(5). It should be possible to work around the >> problem >> creating /usr/local/etc/libmap.d/python.conf with contents: >> >> [python2.7] >> libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1 >> >> [python3.4] >> libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1 >> > > Sure but I'm guessing not all python ports *need* gfortran hence > we shouldn't force all python coded ports to use the gfortran libgcc_s.so libmap.conf(5) manual page documents how to restrict such mappings per-directory. One can create symlink for the interpreter and restrict the mapping for symlink only. > Moreover, the libmap would have to be updated everytime gfortran got > updated Not quite: libgcc_s.so.1 needs mapping for interpreter only as our port building system already creates libgfortran.so with right rpath for libgcc_s.so.1: # ldd /usr/local/lib/gcc8/libgfortran.so.5 /usr/local/lib/gcc8/libgfortran.so.5: libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x80146e000) libz.so.6 => /lib/libz.so.6 (0x8016ad000) libm.so.5 => /lib/libm.so.5 (0x8018c5000) libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x801af3000) libc.so.7 => /lib/libc.so.7 (0x800823000) ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote: > On 2/16/19 6:21 PM, Eugene Grosbein wrote: > > 17.02.2019 8:02, Russell L. Carter wrote: > > > >> Greetings, ... > root@feyerabend> > > So I must dig deeper. Perhaps with rpaths interacting with the system > paths? > > Russell You got it. ;) Except python doesn't have an rpath which is why this keeps coming up over and over again. - Diane -- - d...@freebsd.org d...@db.net http://artemis.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: FreeCAD 0.17 && /lib//libgcc_s.so.1
17.02.2019 22:41, Diane Bruce wrote:
>> Setting rpath for resulting binary should solve the problem.
>
> No no no no no. Not for an interpreter. The interpreter doesn't 'know'
> you are about to load a binary module that needs libgcc_s and until
> it loads something that uses gfortran it doesn't matter
> which libgcc_s so it picks the 'wrong' one.
>
> As my wiki page article says:
> We can rename our libgcc (Yes other complications but...)
>
> We can fix our system libgcc to have the missing functions/data that
> current libgcc has then bump our version
>
> We can use a specific port which PRELOADs the gfortran libgcc_s.so
> e.g. python2_gfortran8 or whatever. (What a mess and it's ugly but
> it would work)
>
> Individual python ports could be modified to do the PRELOAD with
> a tiny sh script e.g. opencad could envoke a small sh script
> that then starts the python interpreter. This would mean exposing the
> PATH from Mk/USES/fortan.mk
>
> e.g. we currently do this:
>
> FFLAGS+=-Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
> FCFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
> LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \
>
> We'd need FRPATH=${LOCALBASE}/lib/gcc${_GCC_VER}
> exposed
>
> blah. I finally just looked at openscad it's a binary not a python script
> As Steve sez it's missing the -Wl,-rpath stuff then
If all involved binaries and libraries in a chain starting from the interpreter
and including libraries have mappings for libgcc_s.so to right file,
the problem should be solved. And libmap.conf(5) should do the job.
___
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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 17, 2019 at 01:35:31PM +0700, Eugene Grosbein wrote:
> 17.02.2019 13:19, Steve Kargl wrote:
>
> > For whatever reason, there are situations where the rpath
> > isn't set in the library. Read the rtld manpage. You're
> > hitting #5 in the list.
>
> Our package building system sets rpath for dependants of gcc8,
> so Fortran libraries (and others) do have rpath for its runtime.
>
> Setting rpath for resulting binary should solve the problem.
No no no no no. Not for an interpreter. The interpreter doesn't 'know'
you are about to load a binary module that needs libgcc_s and until
it loads something that uses gfortran it doesn't matter
which libgcc_s so it picks the 'wrong' one.
As my wiki page article says:
We can rename our libgcc (Yes other complications but...)
We can fix our system libgcc to have the missing functions/data that
current libgcc has then bump our version
We can use a specific port which PRELOADs the gfortran libgcc_s.so
e.g. python2_gfortran8 or whatever. (What a mess and it's ugly but
it would work)
Individual python ports could be modified to do the PRELOAD with
a tiny sh script e.g. opencad could envoke a small sh script
that then starts the python interpreter. This would mean exposing the
PATH from Mk/USES/fortan.mk
e.g. we currently do this:
FFLAGS+=-Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
FCFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \
We'd need FRPATH=${LOCALBASE}/lib/gcc${_GCC_VER}
exposed
blah. I finally just looked at openscad it's a binary not a python script
As Steve sez it's missing the -Wl,-rpath stuff then
- Diane
--
- d...@freebsd.org d...@db.net http://artemis.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: FreeCAD 0.17 && /lib//libgcc_s.so.1
17.02.2019 22:15, Diane Bruce wrote: > Basically all we need is a pre-loader script for interpreters > that run into this such as python. (I suspect there have to be other > interpreters that run into this.) Perhaps something like > python2_gfortran or the like, all it has to do is PRELOAD or modify > the library path so we get the 'right' libgcc_s.so. We already have libmap.conf(5). It should be possible to work around the problem creating /usr/local/etc/libmap.d/python.conf with contents: [python2.7] libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1 [python3.4] libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1 ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sat, Feb 16, 2019 at 09:56:55PM -0800, Steve Kargl wrote: > On Sun, Feb 17, 2019 at 12:37:36PM +0700, Eugene Grosbein wrote: > > 17.02.2019 12:11, Steve Kargl wrot: > > > > > > > > There is a problem with the order of libgcc_s.so.1 > > > in the cache created by ldconfig. rtld will use ... > 4) bump the major library version number for /lib/libgcc.so.1 >to 2; > 5) fix rtld to not fail on the first found library in the cache. >Iterated over all entries and only fail if the library isn't found; Not so easy. I looked at it but it would not be easy. > 6) rename /lib/libgcc_s.so.1 to /lib/libllvm_s.so.1 and teach >llvm/clang/rtld to not misappropriate a well-known GCC library >name. For the record I have been arguing for this for a few years as well. Read my wiki page on it. - Diane -- - d...@freebsd.org d...@db.net http://artemis.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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 17, 2019 at 12:37:36PM +0700, Eugene Grosbein wrote: > 17.02.2019 12:11, Steve Kargl wrot: > > > > > There is a problem with the order of libgcc_s.so.1 > > in the cache created by ldconfig. rtld will use > > the first one it finds. If it fails, it fails. It > > does not look to see if there is a second entry. > > If binary needs specific version of libgcc_s.so.1 installed > with gcc8 port/package, then building system must use specific > rpath, so rtld would not use "the first one it finds". This is a well-known problem with libgcc_s.so.1 and gfortran. You can state whatever you believe should happen, but it does not seem to work that. You have a few options: 1) Add -static to your options; 2) Use LD_LIBRARY_PATH, LD_RUN_PATH to point to /usr/local/lib/gcc8; 3) Add -Wl,-rpath=/usr/local/lib/gcc8 to FFLAGS in /etc/make.conf (check syntax for this one); 4) bump the major library version number for /lib/libgcc.so.1 to 2; 5) fix rtld to not fail on the first found library in the cache. Iterated over all entries and only fail if the library isn't found; 6) rename /lib/libgcc_s.so.1 to /lib/libllvm_s.so.1 and teach llvm/clang/rtld to not misappropriate a well-known GCC library name. -- 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 17, 2019 at 01:13:15PM +0700, Eugene Grosbein wrote:
> 17.02.2019 12:56, Steve Kargl wrote:
>
> >> 17.02.2019 12:11, Steve Kargl wrot:
> >>>
> >>> There is a problem with the order of libgcc_s.so.1
> >>> in the cache created by ldconfig. rtld will use
> >>> the first one it finds. If it fails, it fails. It
> >>> does not look to see if there is a second entry.
> >>
> >> If binary needs specific version of libgcc_s.so.1 installed
> >> with gcc8 port/package, then building system must use specific
> >> rpath, so rtld would not use "the first one it finds".
> >
> > This is a well-known problem with libgcc_s.so.1 and gfortran.
> > You can state whatever you believe should happen, but it does
> > not seem to work that. You have a few options:
> > 1) Add -static to your options;
> > 2) Use LD_LIBRARY_PATH, LD_RUN_PATH to point to
> >/usr/local/lib/gcc8;
> > 3) Add -Wl,-rpath=/usr/local/lib/gcc8 to FFLAGS in /etc/make.conf
> >(check syntax for this one);
> > 4) bump the major library version number for /lib/libgcc.so.1
> >to 2;
> > 5) fix rtld to not fail on the first found library in the cache.
> >Iterated over all entries and only fail if the library isn't found;
> > 6) rename /lib/libgcc_s.so.1 to /lib/libllvm_s.so.1 and teach
> >llvm/clang/rtld to not misappropriate a well-known GCC library
> >name.
> >
>
> When a port from our Ports Collection needs specific version of GCC and its
> runtime libraries,
> it utilizes "USE_GCC=8" and bsd.gcc.mk adds this to make everybody happy:
>
> CFLAGS+=-Wl,-rpath=${_GCC_RUNTIME}
> CXXFLAGS+= -Wl,-rpath=${_GCC_RUNTIME}
> LDFLAGS+= -Wl,-rpath=${_GCC_RUNTIME} -L${_GCC_RUNTIME}
>
> This is your 3) case and this is what I have meant.
FFLAGS+=
For whatever reason, there are situations where the rpath
isn't set in the library. Read the rtld manpage. You're
hitting #5 in the list.
--
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: FreeCAD 0.17 && /lib//libgcc_s.so.1
17.02.2019 12:56, Steve Kargl wrote:
> On Sun, Feb 17, 2019 at 12:37:36PM +0700, Eugene Grosbein wrote:
>> 17.02.2019 12:11, Steve Kargl wrot:
>>
>>>
>>> There is a problem with the order of libgcc_s.so.1
>>> in the cache created by ldconfig. rtld will use
>>> the first one it finds. If it fails, it fails. It
>>> does not look to see if there is a second entry.
>>
>> If binary needs specific version of libgcc_s.so.1 installed
>> with gcc8 port/package, then building system must use specific
>> rpath, so rtld would not use "the first one it finds".
>
> This is a well-known problem with libgcc_s.so.1 and gfortran.
> You can state whatever you believe should happen, but it does
> not seem to work that. You have a few options:
> 1) Add -static to your options;
> 2) Use LD_LIBRARY_PATH, LD_RUN_PATH to point to
>/usr/local/lib/gcc8;
> 3) Add -Wl,-rpath=/usr/local/lib/gcc8 to FFLAGS in /etc/make.conf
>(check syntax for this one);
> 4) bump the major library version number for /lib/libgcc.so.1
>to 2;
> 5) fix rtld to not fail on the first found library in the cache.
>Iterated over all entries and only fail if the library isn't found;
> 6) rename /lib/libgcc_s.so.1 to /lib/libllvm_s.so.1 and teach
>llvm/clang/rtld to not misappropriate a well-known GCC library
>name.
>
When a port from our Ports Collection needs specific version of GCC and its
runtime libraries,
it utilizes "USE_GCC=8" and bsd.gcc.mk adds this to make everybody happy:
CFLAGS+=-Wl,-rpath=${_GCC_RUNTIME}
CXXFLAGS+= -Wl,-rpath=${_GCC_RUNTIME}
LDFLAGS+= -Wl,-rpath=${_GCC_RUNTIME} -L${_GCC_RUNTIME}
This is your 3) case and this is what I have meant.
When someone builds a binary having same requirements but without
writing port/using bsd.gcc.mk, same needs to be done
and everything should just work. Or better create a port.
___
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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 17, 2019 at 01:35:31PM +0700, Eugene Grosbein wrote: > 17.02.2019 13:19, Steve Kargl wrote: > > > For whatever reason, there are situations where the rpath > > isn't set in the library. Read the rtld manpage. You're > > hitting #5 in the list. > > Our package building system sets rpath for dependants of gcc8, > so Fortran libraries (and others) do have rpath for its runtime. > > Setting rpath for resulting binary should solve the problem. It seems that you may want to review the email archives. The issue with libgfortran.so and the wrong libgcc_s.so has come up about once a year for the last 5 to 10 years. -- 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
17.02.2019 13:19, Steve Kargl wrote: > For whatever reason, there are situations where the rpath > isn't set in the library. Read the rtld manpage. You're > hitting #5 in the list. Our package building system sets rpath for dependants of gcc8, so Fortran libraries (and others) do have rpath for its runtime. Setting rpath for resulting binary should solve the problem. ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote: > > So I must dig deeper. Perhaps with rpaths interacting with the system > paths? > Read the rtld manpage. You're hitting #5 in the list, because the first 4 aren't satisified. Now, look at 'ldconfig -r | grep libgcc_s'. -- 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 17, 2019 at 08:21:00AM +0700, Eugene Grosbein wrote: > > I've just did "pkg install gcc8" using my FreeBSD 11.2/amd64 system and got > this: > > # ldd /usr/local/lib/gcc8/libgfortran.so.5 > /usr/local/lib/gcc8/libgfortran.so.5: > libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x80146e000) > libz.so.6 => /lib/libz.so.6 (0x8016ad000) > libm.so.5 => /lib/libm.so.5 (0x8018c5000) > libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x801af3000) > libc.so.7 => /lib/libc.so.7 (0x800823000) > > So, /usr/local/lib/gcc8/libgfortran.so.5 does not depend on /lib/libgcc_s.so.1 > but on /usr/local/lib/gcc8/libgcc_s.so.1 in normal case. > > I assume something is broken in your installation. Try removing gcc8 and > reinstalling > it using package. > There is a problem with the order of libgcc_s.so.1 in the cache created by ldconfig. rtld will use the first one it finds. If it fails, it fails. It does not look to see if there is a second entry. -- 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
17.02.2019 12:11, Steve Kargl wrot: >> # ldd /usr/local/lib/gcc8/libgfortran.so.5 >> /usr/local/lib/gcc8/libgfortran.so.5: >> libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 >> (0x80146e000) >> libz.so.6 => /lib/libz.so.6 (0x8016ad000) >> libm.so.5 => /lib/libm.so.5 (0x8018c5000) >> libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x801af3000) >> libc.so.7 => /lib/libc.so.7 (0x800823000) >> >> So, /usr/local/lib/gcc8/libgfortran.so.5 does not depend on >> /lib/libgcc_s.so.1 >> but on /usr/local/lib/gcc8/libgcc_s.so.1 in normal case. >> >> I assume something is broken in your installation. Try removing gcc8 and >> reinstalling >> it using package. > > There is a problem with the order of libgcc_s.so.1 > in the cache created by ldconfig. rtld will use > the first one it finds. If it fails, it fails. It > does not look to see if there is a second entry. If binary needs specific version of libgcc_s.so.1 installed with gcc8 port/package, then building system must use specific rpath, so rtld would not use "the first one it finds". ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
"Russell L. Carter" writes: > /lib/libgcc_s.so.1 version GCC_4.8.0 required by > /usr/local/lib/gcc8/libgfortran.so.5 not found [...] > Question to experienced porters, how is this best practice solved? Try adding USES=fortran to freecad in order to propagate GCC LDFLAGS as old libgcc_s.so maybe loaded *before* libmed.so sets RPATH. Before Clang/libc++ became default (on x86) a similar conflict existed between libstdc++.so from base system and libstdc++.so from lang/gcc*. ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
17.02.2019 8:58, Russell L. Carter wrote: > On 2/16/19 6:44 PM, Eugene Grosbein wrote: >> 17.02.2019 8:35, Russell L. Carter wrote: >> > Transcribed output from the FreeCAD Testing Framework GUI test all: > > First run of TestApp.All: Run: 212 Failures: 1 Errors: 20 > > which isn't bad at all I suspect. However one of the failures is > > /lib/libgcc_s.so.1 version GCC_4.8.0 required by > /usr/local/lib/gcc8/libgfortran.so.5 not found >> >> Where did you get this from, exactly? >> > > I apologize, I am unsure what you are asking about with respect to the > "this". The output I am showing is literally typed in from the error > display box that happens when I run FreeCAD-git, ie, current git > FreeCAD, in an outside the ports tree bleeding edge version, including > the dependencies, that I am working on. I detailed this in the > original message. I would be delighted to share all my scripts and > patches that got me this far. > > Anyway there is a FreeCAD Test workbench, with an "all" option, right > at the top, and that's where I'm starting on the bug triage. > > Now I got to cook dinner but I will be back at it tomorrow. Something > of an obsession. Plus I have a deck to design. It would be cheaper > to have someone else do this, but shouldn't FreeCAD do it on FreeBSD? Maybe you should use libmap.conf(5) to work around the problem. "ktrace -i" and kdump would be handy to discover exact name of the binary or library for /etc/libmap.conf if FreeCAD-git happens to be not binary but some wrapping script for real binary. ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On 2/16/19 6:44 PM, Eugene Grosbein wrote: 17.02.2019 8:35, Russell L. Carter wrote: Transcribed output from the FreeCAD Testing Framework GUI test all: First run of TestApp.All: Run: 212 Failures: 1 Errors: 20 which isn't bad at all I suspect. However one of the failures is /lib/libgcc_s.so.1 version GCC_4.8.0 required by /usr/local/lib/gcc8/libgfortran.so.5 not found Where did you get this from, exactly? I apologize, I am unsure what you are asking about with respect to the "this". The output I am showing is literally typed in from the error display box that happens when I run FreeCAD-git, ie, current git FreeCAD, in an outside the ports tree bleeding edge version, including the dependencies, that I am working on. I detailed this in the original message. I would be delighted to share all my scripts and patches that got me this far. Anyway there is a FreeCAD Test workbench, with an "all" option, right at the top, and that's where I'm starting on the bug triage. Now I got to cook dinner but I will be back at it tomorrow. Something of an obsession. Plus I have a deck to design. It would be cheaper to have someone else do this, but shouldn't FreeCAD do it on FreeBSD? :-) Best, Russell ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
17.02.2019 8:35, Russell L. Carter wrote: >>> Transcribed output from the FreeCAD Testing Framework GUI test all: >>> >>> First run of TestApp.All: Run: 212 Failures: 1 Errors: 20 >>> >>> which isn't bad at all I suspect. However one of the failures is >>> >>> /lib/libgcc_s.so.1 version GCC_4.8.0 required by >>> /usr/local/lib/gcc8/libgfortran.so.5 not found Where did you get this from, exactly? ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On 2/16/19 6:14 PM, Steve Kargl wrote: On Sat, Feb 16, 2019 at 06:02:11PM -0700, Russell L. Carter wrote: /lib/libgcc_s.so.1 version GCC_4.8.0 required by /usr/local/lib/gcc8/libgfortran.so.5 not found Question to experienced porters, how is this best practice solved? setenv LD_LIBRARY_PATH /usr/local/lib/gcc8 setenv LD_RUN_PATH /usr/local/lib/gcc8 Steve, script: #! /bin/sh export LD_LIBRARY_PATH=/usr/local/lib/gcc8 export LD_RUN_PATH=/usr/local/lib/gcc8 FreeCAD $* And now the errors are different with no /lib/libgcc_s.so.1 error, but if I rerun the tests in the GUI instance, I return to the libgcc_s.so.1 problem. Maybe a lost environment in there somewhere. Well I will be back at it tomorrow. Thanks, Russell ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On 2/16/19 6:21 PM, Eugene Grosbein wrote: 17.02.2019 8:02, Russell L. Carter wrote: Greetings, Restarting the FreeCAD 0.17 discussion on a different tangent. As I mentioned before I am building (for now) outside of the ports tree FreeCAD-git + Coin-hg + QT5 + med-4.0.0. I want to particularly thank very much all the porting work that has been done so far, I wouldn't have been able to get as far as I have without it. french/med (french?) requires fortran, and for ports gfortran is apparently the only option. gfortran depends on libgcc_s.so.1, which is FreeBSD's (only?) version of dll hell. Transcribed output from the FreeCAD Testing Framework GUI test all: First run of TestApp.All: Run: 212 Failures: 1 Errors: 20 which isn't bad at all I suspect. However one of the failures is /lib/libgcc_s.so.1 version GCC_4.8.0 required by /usr/local/lib/gcc8/libgfortran.so.5 not found This is probably fatal to practical use of FreeCAD on FreeBSD. I was able to open most of my previous models, created on debian-testing, but some were fail. 2 threads, no happy ending: https://lists.freebsd.org/pipermail/freebsd-ports/2018-May/113336.html https://lists.freebsd.org/pipermail/freebsd-python/2016-January/009672.html Question to experienced porters, how is this best practice solved? I've just did "pkg install gcc8" using my FreeBSD 11.2/amd64 system and got this: # ldd /usr/local/lib/gcc8/libgfortran.so.5 /usr/local/lib/gcc8/libgfortran.so.5: libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x80146e000) libz.so.6 => /lib/libz.so.6 (0x8016ad000) libm.so.5 => /lib/libm.so.5 (0x8018c5000) libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x801af3000) libc.so.7 => /lib/libc.so.7 (0x800823000) So, /usr/local/lib/gcc8/libgfortran.so.5 does not depend on /lib/libgcc_s.so.1 but on /usr/local/lib/gcc8/libgcc_s.so.1 in normal case. I assume something is broken in your installation. Try removing gcc8 and reinstalling it using package. I have similar libgfortran.so.5 installation linkage: root@feyerabend> ldd /usr/local/lib/gcc8/libgfortran.so.5 /usr/local/lib/gcc8/libgfortran.so.5: libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x80126d000) libz.so.6 => /lib/libz.so.6 (0x80066a000) libm.so.5 => /lib/libm.so.5 (0x800684000) libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x8014ac000) libc.so.7 => /lib/libc.so.7 (0x800249000) root@feyerabend> So I must dig deeper. Perhaps with rpaths interacting with the system paths? Russell ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
17.02.2019 8:02, Russell L. Carter wrote: > Greetings, > > Restarting the FreeCAD 0.17 discussion on a different tangent. > > As I mentioned before I am building (for now) outside of the ports > tree FreeCAD-git + Coin-hg + QT5 + med-4.0.0. I want to particularly > thank very much all the porting work that has been done so far, I > wouldn't have been able to get as far as I have without it. > > french/med (french?) requires fortran, and for ports gfortran is > apparently the only option. gfortran depends on libgcc_s.so.1, which > is FreeBSD's (only?) version of dll hell. > > Transcribed output from the FreeCAD Testing Framework GUI test all: > > First run of TestApp.All: Run: 212 Failures: 1 Errors: 20 > > which isn't bad at all I suspect. However one of the failures is > > /lib/libgcc_s.so.1 version GCC_4.8.0 required by > /usr/local/lib/gcc8/libgfortran.so.5 not found > > This is probably fatal to practical use of FreeCAD on FreeBSD. I was > able to open most of my previous models, created on debian-testing, > but some were fail. > > 2 threads, no happy ending: > > https://lists.freebsd.org/pipermail/freebsd-ports/2018-May/113336.html > https://lists.freebsd.org/pipermail/freebsd-python/2016-January/009672.html > > Question to experienced porters, how is this best practice solved? I've just did "pkg install gcc8" using my FreeBSD 11.2/amd64 system and got this: # ldd /usr/local/lib/gcc8/libgfortran.so.5 /usr/local/lib/gcc8/libgfortran.so.5: libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x80146e000) libz.so.6 => /lib/libz.so.6 (0x8016ad000) libm.so.5 => /lib/libm.so.5 (0x8018c5000) libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x801af3000) libc.so.7 => /lib/libc.so.7 (0x800823000) So, /usr/local/lib/gcc8/libgfortran.so.5 does not depend on /lib/libgcc_s.so.1 but on /usr/local/lib/gcc8/libgcc_s.so.1 in normal case. I assume something is broken in your installation. Try removing gcc8 and reinstalling it using package. ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sat, Feb 16, 2019 at 06:02:11PM -0700, Russell L. Carter wrote: > > /lib/libgcc_s.so.1 version GCC_4.8.0 required by > /usr/local/lib/gcc8/libgfortran.so.5 not found > > > Question to experienced porters, how is this best practice solved? > setenv LD_LIBRARY_PATH /usr/local/lib/gcc8 setenv LD_RUN_PATH /usr/local/lib/gcc8 -- 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"
