From owner-freebsd-ports@freebsd.org Sun Feb 24 20:09:30 2019 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA53A1509BE3 for ; Sun, 24 Feb 2019 20:09:30 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 97FE784AFE; Sun, 24 Feb 2019 20:09:29 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x1OK9FBh026848 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 24 Feb 2019 12:09:15 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1OK9ELq026847; Sun, 24 Feb 2019 12:09:14 -0800 (PST) (envelope-from sgk) Date: Sun, 24 Feb 2019 12:09:14 -0800 From: Steve Kargl To: =?utf-8?Q?T=C4=B3l?= Coosemans Cc: Diane Bruce , Dima Pasechnik , gerald@freebsd.org, Dave Horsfall , FreeBSD Ports Subject: Re: FreeCAD 0.17 && /lib//libgcc_s.so.1 Message-ID: <20190224200914.GA26706@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu 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> <20190223000620.GA12700@troutmask.apl.washington.edu> <20190223183117.GA65065@night.db.net> <20190224142150.685debe4@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190224142150.685debe4@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 97FE784AFE X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.27 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.87)[0.873,0]; IP_SCORE(0.05)[ip: (0.11), ipnet: 128.95.0.0/16(0.17), asn: 73(0.06), country: US(-0.07)]; TAGGED_RCPT(0.00)[freebsd]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; RCPT_COUNT_FIVE(0.00)[6]; NEURAL_HAM_LONG(-0.20)[-0.202,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_SPAM_MEDIUM(0.85)[0.853,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 20:09:30 -0000 On Sun, Feb 24, 2019 at 02:21:50PM +0100, Tijl Coosemans wrote: > On Sat, 23 Feb 2019 13:31:17 -0500 Diane Bruce 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 > >> 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