Date: Thu, 21 Feb 2019 10:24:51 -0800 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: =?utf-8?Q?T=C4=B3l?= Coosemans <tijl@freebsd.org> Cc: Diane Bruce <db@db.net>, "Russell L. Carter" <rcarter@pinyon.org>, Eugene Grosbein <eugen@grosbein.net>, FreeBSD Ports ML <freebsd-ports@freebsd.org> Subject: Re: FreeCAD 0.17 && /lib//libgcc_s.so.1 Message-ID: <20190221182451.GA82216@troutmask.apl.washington.edu> In-Reply-To: <20190221180515.39c79ce6@kalimero.tijl.coosemans.org> References: <a2102b4e-7d7a-7d5b-2ba1-b9a14f8574f6@pinyon.org> <f6a45ec9-7ae4-d9ba-f71c-f2ef8c235039@grosbein.net> <416689e6-37f9-17ec-54d8-0d224c26f30f@pinyon.org> <20190217151604.GB68620@night.db.net> <20190221180515.39c79ce6@kalimero.tijl.coosemans.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote:
> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce <db@db.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190221182451.GA82216>