On Sat, 23 Feb 2019 13:31:17 -0500 Diane Bruce <d...@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 >> <s...@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'm not asking that he stops maintaining gcc. All I want is a little more pragmatism. User experience is more important than the patch being in the perfect shape to be submitted upstream. Be more practical instead of idealistic. The -rpath problem affects all users. Maintaining a patch in the ports tree affects just the maintainer. Make decisions based on weighing pros and cons. Ideals are just guidelines. If a situation is bad enough then committing an imperfect patch is better than doing nothing. I'm a user of gcc on FreeBSD. I'm not a gcc developer and I don't want to become one. If a maintainer wants patches to be in a perfect shape he's asking users to be developers. This doesn't work. Either the maintainer has to improve the patch himself or he has to play the role of liaison between the user and an upstream developer. If this takes too long and the situation is bad enough then he has to be willing to add the imperfect patch to the port. _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
