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

Mon Feb 25 12:46:16 UTC 2019

On Mon, Feb 25, 2019 at 1:58 AM Dima Pasechnik
<dimpase+freebsd at gmail.com> wrote:
>
> On Sun, Feb 24, 2019 at 8:09 PM Steve Kargl
> <sgk at troutmask.apl.washington.edu> wrote:
> >
> > On Sun, Feb 24, 2019 at 02:21:50PM +0100, Tĳl Coosemans wrote:
> > > On Sat, 23 Feb 2019 13:31:17 -0500 Diane Bruce <db at db.net> wrote:
> > > > On Sat, Feb 23, 2019 at 10:52:03AM +0000, Dima Pasechnik wrote:
> > > >> On Sat, Feb 23, 2019 at 12:07 AM Steve Kargl
> > > >> <sgk at troutmask.apl.washington.edu> wrote:
> > > >>> On Sat, Feb 23, 2019 at 09:19:01AM +1100, Dave Horsfall wrote:
> > > >>>> On Fri, 22 Feb 2019, Tĳl 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 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