Date: Sun, 24 Feb 2019 12:09:14 -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>, Dima Pasechnik <dimpase+freebsd@gmail.com>, gerald@freebsd.org, Dave Horsfall <dave@horsfall.org>, FreeBSD Ports <freebsd-ports@freebsd.org> Subject: Re: FreeCAD 0.17 && /lib//libgcc_s.so.1 Message-ID: <20190224200914.GA26706@troutmask.apl.washington.edu> In-Reply-To: <20190224142150.685debe4@kalimero.tijl.coosemans.org> References: <416689e6-37f9-17ec-54d8-0d224c26f30f@pinyon.org> <20190217151604.GB68620@night.db.net> <20190221180515.39c79ce6@kalimero.tijl.coosemans.org> <092b17f0-6fbf-662e-1061-403442248abd@pinyon.org> <20190222140407.2145c11e@kalimero.tijl.coosemans.org> <alpine.BSF.2.21.9999.1902230913380.84718@aneurin.horsfall.org> <20190223000620.GA12700@troutmask.apl.washington.edu> <CAAWYfq20PgO9RoaN2esyqf-dc2xyqfmkLVaSe8yrx-X4E1s=ZQ@mail.gmail.com> <20190223183117.GA65065@night.db.net> <20190224142150.685debe4@kalimero.tijl.coosemans.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 24, 2019 at 02:21:50PM +0100, Tijl Coosemans wrote: > On Sat, 23 Feb 2019 13:31:17 -0500 Diane Bruce <db@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@troutmask.apl.washington.edu> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190224200914.GA26706>