FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ science/psychopy| 1.90.3 | 3.0.5 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ 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 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 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"
Committer required for textproc/sigil update
Hi, Could a committer please review, and possibly commit: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235873 Thanks! -- Jonathan Chen ___ 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 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 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"
Missing modules in devel/rust-cbindgen
In trying to compile /usr/ports/devel/rust-cbindgen on an rpi3 running -current make fails with errors such as error[E0412]: cannot find type `c_long` in the crate root It's tempting to think this is some sort of configuration error. Can anyone suggest a workaround? There don't seem to be any user-configurable options. Rust itself now builds successfully on the rpi3, I think rust-cbindgen might be the only remaining obstacle to compiling some flavor of firefox. Thanks for reading, and any guidance! bob prohaska ___ 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"
sysutils/geomWatch outage due to mail/libesmtp show_bug.cgi?id=229017
Hello, one not so prominent openssl111 victim is mail/libesmtp, already reported in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229017 This prevents sysutils/geomWatch to run on FreeBSD 12. Unfortunately I can't provide an aedequate patch. Anybody else who already ironed out openssl compat nits? Thanks, -harry ___ 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, 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 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, 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"
