Re: FreeCAD 0.17 && /lib//libgcc_s.so.1

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: FreeCAD 0.17 && /lib//libgcc_s.so.1

Gerald Pfeifer
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!

Gerald
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"

patch-gfortran-libgcc (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

libgcc_s.so.1, Fortran, and the world (was: FreeCAD 0.17 && /lib//libgcc_s.so.1)

Gerald Pfeifer
Hmm, I received zero feedback on this proposal, when it appeared
important for a number of users.

What's your take, Andreas, Tijl (your patch essentially with a bit
of an updated description), and toolchain?

Gerald

On Wed, 27 Feb 2019, Gerald Pfeifer wrote:
> 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@!
:

> 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!
>
> Gerald
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"

patch-gfortran-libgcc (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: libgcc_s.so.1, Fortran, and the world (was: FreeCAD 0.17 && /lib//libgcc_s.so.1)

freebsd-toolchain mailing list


On 2019-Apr-7, at 22:16, Gerald Pfeifer <gerald at pfeifer.com> wrote:

> Hmm, I received zero feedback on this proposal, when it appeared
> important for a number of users.
>
> What's your take, Andreas, Tijl (your patch essentially with a bit
> of an updated description), and toolchain?
>
> Gerald
>
> On Wed, 27 Feb 2019, Gerald Pfeifer wrote:
>> 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@!
> :
>> 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!
>>
>

I'm not sure the following will be considered important
for the above, but I'll note it in case.

A problem of sorts for WITHOUT_LLVM_LIBUNWIND= contexts:

For contexts using WITHOUT_LLVM_LIBUNWIND= that might not use
gcc 4.2.1 , use of the system libgcc_s is problematical:
the old libunwind code does not correctly (not completely)
implement DW_CFA_remember_state and DW_CFA_restore_state .

It happens that g++ 4.2.1 (mostly?) avoids generating
code that needs them. But modern clang++ and g++ do
generate code frequently that needs DW_CFA_remember_state
and DW_CFA_restore_state to work.

Because I experiment with clang/clang++ and devel/powerpc64-gcc
for buildworld buildkernel for powerpc64 (and powerpc), I use
a patched libgcc_s when I try WITHOUT_LLVM_LIBUNWIND= . John Baldwin
and others have expressed wanting to jump to WITH_LLLVM_LIBUNWIND=
use (not with gcc 4.2.1), without fixing the old code first.

Out of the mess described later: powerpc64 and powerpc are not yet
ready for general, non-experimental WITH_LLVM_LIBUNWIND= use.

I do not know the status of any potential blocking issues for
switching for other architectures officially still using gcc/g++
4.2.1 .


powerpc64 and powerpc details:

WITH_LLVM_LIBUNWIND= has https://reviews.llvm.org/D59694 by Leandro
Lupori in process for powerpc64 ( for using WITHOUT_LIB32= ). It
should allow use of WITH_LLVM_LIBUNWIND= WITHOUT_LIB32= . [As stands
llvm's libunwind mungs up handling r2 (the powerpc64 TOC register).]
https://reviews.llvm.org/D59694 is associated with
https://bugs.llvm.org//show_bug.cgi?id=41050 . (That last has a messy
comment history from my figuring out information as I went.)

Handling thrown C++ exceptions need not be the only issue blocking
system-clang use for one or both powerpc family branches. For 32-bit
powerpc it is known to not be the only issue. powerpc64 via clang/clang++
ends up with a WITH_LIB32= issue from some of the 32-bit powerpc related
issues.

But even without that, clang/clang++ for buildworld does not
support the implicit Dwarf-like EH generation that the old code
requires for its use of __builtin_eh_return . This leads to any
thrown c++ exdpetion crashing the program invovled. There is
https://bugs.llvm.org//show_bug.cgi?id=26844 for this issue.
(It has been around a while.)

devel/powerpc644-gcc does the right thing for this when used
for buildworld --but has its own issues that make WITH_LIB32=
still useless last I checked.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: libgcc_s.so.1, Fortran, and the world (was: FreeCAD 0.17 && /lib//libgcc_s.so.1)

Tijl Coosemans
In reply to this post by Gerald Pfeifer
On Mon, 8 Apr 2019 13:16:15 +0800 (WITA) Gerald Pfeifer
<[hidden email]> wrote:
> This patch make 3 the default for gfortran.

s/make/makes/ but otherwise the patch looks fine.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: libgcc_s.so.1, Fortran, and the world (was: FreeCAD 0.17 && /lib//libgcc_s.so.1)

Tijl Coosemans
In reply to this post by freebsd-toolchain mailing list
On Sun, 7 Apr 2019 23:57:12 -0700 Mark Millard via freebsd-ports
<[hidden email]> wrote:

> On 2019-Apr-7, at 22:16, Gerald Pfeifer <gerald at pfeifer.com> wrote:
>> Hmm, I received zero feedback on this proposal, when it appeared
>> important for a number of users.
>>
>> What's your take, Andreas, Tijl (your patch essentially with a bit
>> of an updated description), and toolchain?
>>
>> Gerald
>>
>> On Wed, 27 Feb 2019, Gerald Pfeifer wrote:
>>> 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@!
>>>
>>> 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!
>
> I'm not sure the following will be considered important
> for the above, but I'll note it in case.

I don't think it is relevant.  The patch only affects gfortran, not any
C/C++ compiler, and it only affects programs that currently don't run
because system libgcc_s is loaded as a dependency of some library while
another library later in the dependency chain needs gcc libgcc_s.  The
patch fixes this case by eliminating the need for gcc libgcc_s.  It does
not change which libgcc_s is loaded so any problem in the system
libgcc_s affects the same programs before and after the patch.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: libgcc_s.so.1, Fortran, and the world (was: FreeCAD 0.17 && /lib//libgcc_s.so.1)

Gerald Pfeifer
In reply to this post by Tijl Coosemans
On Mon, 8 Apr 2019, Tijl Coosemans wrote:
>> This patch make 3 the default for gfortran.
> s/make/makes/ but otherwise the patch looks fine.

Thank you, Tijl.

I updated lang/gcc8 (including bumping its PORTREVISION) and will
apply the same to lang/gcc8-devel next, and then lang/gcc9-devel
so lang/gcc9 will then get it as well.

Hope this simplifies things for our users!

Gerald
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"