Re: bogus warning from pkg
On Mon, Feb 15, 2021 at 08:44:46PM -0800, Mark Millard wrote: > > Do you use: > > https://www.freshports.org/ports-mgmt/port-maintenance-tools/ > First port installed on any system is pkg. Second port installed is portmaster. Everything after that is installed with portmaster. -- Steve ___ 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"
Re: bogus warning from pkg
On Mon, Feb 15, 2021 at 08:18:13PM -0800, Mark Millard wrote: > Steve Kargl sgk at troutmask.apl.washington.edu wrote on > Tue Feb 16 02:14:06 UTC 2021 : > > > On Mon, Feb 15, 2021 at 05:10:54PM -0800, Mark Millard via freebsd-ports > > wrote: > > > Steve Kargl sgk at troutmask.apl.washington.edu wrote on > > > Mon Feb 15 20:39:19 UTC 2021 : > > > > > > > Step 1). Install FreeBSD 13.0 on empty disk. > > > > Step 2). Install git from ports and grab FreeBSD 14.0 src. > > > > Step 3). Buildworld/kernel for FreeBSD 14.0 > > > > Step 4). Install FreeBSD 14.0 and reboot. > > > > Step 5). Delete all ports. > > > > Step 6). Re-install pkg, portmaster, and 589 other ports. > > > > > > It does not sound like Step 6 was "rebuild ports and install" > > > but just pkg install use, at least for pkg itself. > > > > Ports are rebuilt on the system as the pre-built ports > > have options selected that do not match the requirements > > of the system. It takes a week or more to rebuild > > everything, which why I'm concerned with the bogus > > warning and whether 'pkg bootstrap -f' would rebuild > > everything. > > > > I also do > > > > % cd /usr/ports > > % svn update > > % make fetchindex > > % pkg audit -qF > > > > before I build any port. That third step pulls down > > the INDEX-14, which again leads to confusion when pkg > > issues a warning about 13. > > If you still have the context to do the comparison: > > How does the output of "pkg info pkg" compare to: > > . . . > Architecture : FreeBSD:13:amd64 > . . . > Annotations: > FreeBSD_version: 13? > . . . > > Does it have "14"s instead of "13"s? > I simply did a 'portmaster -Byd pkg' and did a rebuild and re-install of pkg. That seems to have mysteriously fixed the issue. I'll chalk this up to another FreeBSD heisenbug. -- Steve ___ 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"
Re: bogus warning from pkg
On Mon, Feb 15, 2021 at 05:10:54PM -0800, Mark Millard via freebsd-ports wrote: > Steve Kargl sgk at troutmask.apl.washington.edu wrote on > Mon Feb 15 20:39:19 UTC 2021 : > > > Step 1). Install FreeBSD 13.0 on empty disk. > > Step 2). Install git from ports and grab FreeBSD 14.0 src. > > Step 3). Buildworld/kernel for FreeBSD 14.0 > > Step 4). Install FreeBSD 14.0 and reboot. > > Step 5). Delete all ports. > > Step 6). Re-install pkg, portmaster, and 589 other ports. > > It does not sound like Step 6 was "rebuild ports and install" > but just pkg install use, at least for pkg itself. Ports are rebuilt on the system as the pre-built ports have options selected that do not match the requirements of the system. It takes a week or more to rebuild everything, which why I'm concerned with the bogus warning and whether 'pkg bootstrap -f' would rebuild everything. I also do % cd /usr/ports % svn update % make fetchindex % pkg audit -qF before I build any port. That third step pulls down the INDEX-14, which again leads to confusion when pkg issues a warning about 13. -- Steve ___ 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"
Re: bogus warning from pkg
On Mon, Feb 15, 2021 at 08:56:51PM +, RW via freebsd-ports wrote: > On Mon, 15 Feb 2021 12:39:13 -0800 > Steve Kargl wrote: > > > > BTW, there is no documentation as what 'pkg bootstrap -f' > > does. In particular, the -f option is no described. > > > >From pkg(8) (in 12.2): > > bootstrap > This is for compatibility with the pkg(7) bootstrapper. > If pkg is already installed, nothing is done. > > If invoked with the -f flag an attempt will be made to > reinstall pkg from remote repository. > > > >From pkg(7) > > pkg bootstrap [-f] > Attempt to bootstrap and do not forward anything to > pkg(8) after it is installed. If the -f flag is > specified, then pkg(8) will be fetched and installed > regardless if it is already installed. I was looking for 'man pkg-bootstrap' like 'man pkg-info' or other pkg commands. -- Steve ___ 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"
Re: bogus warning from pkg
On Mon, Feb 15, 2021 at 12:01:47PM -0800, Kevin Oberman wrote: > On Mon, Feb 15, 2021 at 11:10 AM Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > > > I have a system installed from late January FreeBSD-current > > sources and at that point an up-to-date ports tree. All > > installed ports where builtin after I installed FreeBSD. So, > > I am running FreeBSD-14.0. For some reason, I am getting > > bogus warnings from pkg. > > > > % pkg info > /dev/null > > pkg: Warning: Major OS version upgrade detected. Running \ > > "pkg bootstrap -f" recommended > > > > Short of running the bootstrap command, how do I get > > rid of these messages, which are clearly bogus. > > > > -- > > Steve > > > Are you sure that you reinstalled pkg since the move to 14? That message > means that pkg was built on a prior version of FreeBSD. As you build ports > and don't do packages, just build and install pkg and that should do the > trick. Step 1). Install FreeBSD 13.0 on empty disk. Step 2). Install git from ports and grab FreeBSD 14.0 src. Step 3). Buildworld/kernel for FreeBSD 14.0 Step 4). Install FreeBSD 14.0 and reboot. Step 5). Delete all ports. Step 6). Re-install pkg, portmaster, and 589 other ports. BTW, there is no documentation as what 'pkg bootstrap -f' does. In particular, the -f option is no described. -- Steve ___ 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"
bogus warning from pkg
I have a system installed from late January FreeBSD-current sources and at that point an up-to-date ports tree. All installed ports where builtin after I installed FreeBSD. So, I am running FreeBSD-14.0. For some reason, I am getting bogus warnings from pkg. % pkg info > /dev/null pkg: Warning: Major OS version upgrade detected. Running \ "pkg bootstrap -f" recommended Short of running the bootstrap command, how do I get rid of these messages, which are clearly bogus. -- Steve ___ 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"
Re: DEFAULT_VERSIONS+=llvm=90 ignored?
On Sat, Dec 05, 2020 at 01:18:34AM -0800, Mark Millard wrote: > Steve Kargl sgk at troutmask.apl.washington.edu wrote on: > > > > Well, I guess that pretty much kills LLVM_DEFAULT for any > > modern hardware (even a 8 year old laptop) that uses drm > > unless a user wants base-system llvm, llvm90, and llvm10 > > installed. One will certainly be able to compile any > > c/c++ thrown ones way. > > LLVM's API seems to be unstable enough from LLVM release to > LLVM release that maintaining many-release build compatibility > for projects using the LLVM API is not all that common. I'm well aware the llvm API instability, which comes back to the irrelevance of LLVM_DEFAULT. Someday llvm may get it's act together. -- Steve ___ 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"
Re: DEFAULT_VERSIONS+=llvm=90 ignored?
On Fri, Dec 04, 2020 at 11:41:41PM +0100, Jan Beich wrote: > Steve Kargl writes: > > > It takes a long time to compile on my laptop. I have > > > > DEFAULT_VERSIONS+=llvm=90 > > Why do you need to redefine current default? Simply changed /etc/make.conf on my laptop from 80 to 90 when I got a similar problem trying to rebuild gnuplot. Getting llvm10 when LLVM_DEFAULT=80 or 90 seems dubious. > Mk/bsd.default-versions.mk: > LLVM_DEFAULT?=90 > > > % portmaster -Byd gnuplot > > ... > > Install devel/llvm10 > > ... > > Install devel/llvm90 > > devel/llvm10 is pinned by graphics/mesa-* likely to reduce QA after a > fiasco in bug 239682. Trying to unpin in bug 250869 was rejected. > > graphics/mesa-dri/Makefile.common: > LLVM_DEFAULT= 10 Well, I guess that pretty much kills LLVM_DEFAULT for any modern hardware (even a 8 year old laptop) that uses drm unless a user wants base-system llvm, llvm90, and llvm10 installed. One will certainly be able to compile any c/c++ thrown ones way. -- Steve ___ 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"
DEFAULT_VERSIONS+=llvm=90 ignored?
It takes a long time to compile on my laptop. I have DEFAULT_VERSIONS+=llvm=90 in my /etc/make.conf. I go to update gnuplot and get % portmaster -Byd gnuplot ... Install devel/llvm10 ... Install devel/llvm90 Does it really take two versions of llvm to compile gnuplot and dependencies? Is something broken in the ports *.mk files? -- Steve ___ 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"
[PATCH] math/openlibm is broken on i386
Someone ought to apply this patch to the openlibm port. Index: Makefile === --- Makefile (revision 544886) +++ Makefile (working copy) @@ -16,6 +16,7 @@ BROKEN_armv6= fails to compile: a parameter list without types is only allowed in a function definition BROKEN_armv7= fails to compile: a parameter list without types is only allowed in a function definition +BROKEN_i386= Numerical inaccuracies: https://github.com/JuliaMath/openlibm/issues/215 BROKEN_mips= fails to compile: No rule to make target mips/Make.files BROKEN_mips64= fails to compile: No rule to make target mips64/Make.files -- Steve ___ 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"
Re: Why lang/gcc9 depends native-binutils ?
On Tue, Jul 21, 2020 at 11:33:13AM +0900, KIRIYAMA Kazuhiko wrote: > > lang/gcc9 depends devel/binutils with FLAVOR=native, so gcc9 > compilation stopped at devel/binutils. Why lang/gcc9 depends > native-binutils ? > Just a guess. LTO. -- Steve ___ 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"
Re: Json-c, bind, and updating
On Tue, Jun 09, 2020 at 11:45:28PM -0600, @lbutlr wrote: > This has happened in the past, but it happened again this weekend when an > update to ;ibjson-c did not update bind, rendering bind unable to load > libjson-c.so.4 because it had been replaced with libjson-c.so.5. > man libmap.conf This allows you to associate libjson-c.so.4 with *.5 without doing the symlink, which you'll need to remember to remove in the future. My libmap.conf currently has % cat /etc/libmap.conf includedir /usr/local/etc/libmap.d libicui18n.so.66 libicui18n.so.67 libicuuc.so.66libicuuc.so.67 libevent-2.1.so.6 libevent-2.1.so.7 libncurses.so.8 libncurses.so.9 libncursesw.so.8 libncursesw.so.9 because it seems like everything (indirectly) depends on libncurses change and the icu port. Eventually, portmaster and I catch up and libmap.conf entries are removed. -- Steve ___ 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"
Re: current: cd /lib ; ln -s libncurses.so.9 libncurses.so.8 xterm & ffox
On Wed, Apr 01, 2020 at 08:01:35PM +0200, Dimitry Andric wrote: > > Yeah, this ncurses bump was handled pretty badly, as it breaks almost all > installed ports (and a bunch of base programs too, if you are unlucky). > Isn't there any compat package for it yet? > % cat /etc/libmap.conf ... libncurses.so.8 libncurses.so.9 libncursesw.so.8 libncursesw.so.9 HTH -- Steve ___ 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"
Re: mail/junkfilter is several broken
On Thu, Jan 02, 2020 at 12:22:20PM +0100, Stefan Eßer wrote: > Am 01.01.20 um 22:04 schrieb Steve Kargl: > > For users of mail/junkfilter, it now will filter all emails claiming > > a "Bad Date line". The following patch seems to fix the problem for > > the next decade. > > Hi Steve, > > thank you for providing a patch. Since the maintainer (gsutter) has > not been active in FreeBSD for a long time (AFAICT) and due to the > difference in time zones, I have taken liberty to apply the fix to > the port. > > I have sent mail to Gregory who probably will want to apply the fix > to the sourceforge repo and to remove the patch, but the fixed port > will allow to keep junkfilter working, meanwhile. > Thanks for the quick response. I could not tell from the SF page whether junkfilter was still being maintained or not. I find junkfilter to be a handy way to deal with email, but having everything flagged as spam was a little too much. -- Steve ___ 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"
mail/junkfilter is several broken
For users of mail/junkfilter, it now will filter all emails claiming
a "Bad Date line". The following patch seems to fix the problem for
the next decade.
--- junkfilter.three.orig 2020-01-01 12:59:56.005681000 -0800
+++ junkfilter.three2020-01-01 13:00:26.254199000 -0800
@@ -56,7 +56,7 @@
* ! $ ^Date:$JFWS((Sun|Mon|Tue|Wed|Thu|Fri|Sat),$JFWS)?\
(0?[1-9]|[12][0-9]|3[01])$JFWS\
(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)$JFWS\
-((19)?[789][0-9]|(20)?[01][0-9])$JFWS\
+((19)?[789][0-9]|(20)?[012][0-9])$JFWS\
(0?[0-9]|1[0-9]|2[0-3]):(0?|[1-5])[0-9](:(0?|[1-5])[0-9])?$JFWS\
(([+-][0-1][0-4]([03]0|45))|("?\(?(UT|GMT|EST|EDT|CST|CDT|MST|MDT|PST|PDT|[A-I]|[K-Z])\)?"?))?
{ JFMATCH="$JFSEC: Bad Date line" INCLUDERC=$JFDIR/junkfilter.match }
Suggest either installing the patch or marking the port as broken.
--
Steve
___
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"
Re: XXX needs Python 3.4 at least, but 2.7 was specified
On Wed, Dec 25, 2019 at 07:05:50PM +, Montgomery-Smith, Stephen wrote: > > I agree with Franco. I am surprised that this error has been known for > so long, and not fixed, when at least one effective solution exists. > Surely, you're joking. It took more than 2 years to get a 2-line patch to the python committed, and AFAICT, the commit was done by portmgr instead python@. https://lists.freebsd.org/pipermail/freebsd-ports/2019-December/117300.html https://lists.freebsd.org/pipermail/svn-ports-all/2019-December/235695.html -- Steve ___ 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"
Re: python support appears broken in the ports trree
On Tue, Dec 10, 2019 at 04:47:06PM -0800, Chris wrote: > I struggled all day yesterday with various ports barfing with similar > python messages. So today I blew everything off the disk, and started > from scratch. Which only repeats what happened yesterday. Is python > multiplicity no longer available? Or? > Empirical evidence suggests that answer is "yes". -- Steve ___ 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"
Re: python36 is still broken.
On Fri, Dec 06, 2019 at 11:30:29PM +, Dima Pasechnik wrote: > The patch in question is in Python 3.7, cf. > https://github.com/python/cpython/pull/12046 > how about switching to this version? > Is 3.7 the default version of python used by ports? How does switching fix ports that require 2.7? I'll simply be direct. It is a 2-line patch that renames a static function in a single file. Why is so difficult for python@ and/or ports@ to include the patch for the various python ports. -- Steve ___ 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"
Re: python36 is still broken.
On Fri, Dec 06, 2019 at 03:49:46PM -0700, Adam Weinberger wrote:
> On Fri, Dec 6, 2019 at 11:41 AM Steve Kargl
> wrote:
> >
> > This has been reported for many years and there are open bug reports.
> > Any chance that the this will be fixed.
> >
> >
> > --- work/Python-3.6.9/Modules/mathmodule.c.orig 2019-12-06
> > 10:33:39.232673000 -0800
> > +++ work/Python-3.6.9/Modules/mathmodule.c 2019-12-06
> > 10:34:53.288616000 -0800
> > @@ -67,7 +67,7 @@
> > static const double logpi = 1.144729885849400174143427351353058711647;
> >
> > static double
> > -sinpi(double x)
> > +a_really_bad_idea_sinpi(double x)
> > {
> > double y, r;
> > int n;
> > @@ -296,7 +296,7 @@
> > integer. */
> > if (absx > 200.0) {
> > if (x < 0.0) {
> > -return 0.0/sinpi(x);
> > +return 0.0/a_really_bad_idea_sinpi(x);
> > }
> > else {
> > errno = ERANGE;
>
> Hi Steve,
>
> WIthout context it's hard to advise. What PRs with that patch exist?
> Have they been responded to or have they been ignored? Team immunity
> from PR timeouts no longer exists, so if the problem needs a fix let's
> fix it.
>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232792
As noted in the PR, it has been reported to the lists
https://lists.freebsd.org/pipermail/freebsd-ports/2017-June/109093.html
https://lists.freebsd.org/pipermail/freebsd-ports/2017-September/110229.html
I'll refrain from commenting further.
--
Steve
___
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"
python36 is still broken.
This has been reported for many years and there are open bug reports.
Any chance that the this will be fixed.
--- work/Python-3.6.9/Modules/mathmodule.c.orig 2019-12-06 10:33:39.232673000
-0800
+++ work/Python-3.6.9/Modules/mathmodule.c 2019-12-06 10:34:53.288616000
-0800
@@ -67,7 +67,7 @@
static const double logpi = 1.144729885849400174143427351353058711647;
static double
-sinpi(double x)
+a_really_bad_idea_sinpi(double x)
{
double y, r;
int n;
@@ -296,7 +296,7 @@
integer. */
if (absx > 200.0) {
if (x < 0.0) {
-return 0.0/sinpi(x);
+return 0.0/a_really_bad_idea_sinpi(x);
}
else {
errno = ERANGE;
--
Steve
___
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"
Re: Checking you the maintainer of a port?
On Wed, Nov 27, 2019 at 02:03:33PM -0700, @lbutlr wrote: > I thought that the maintainer of a port was listed somewhere in the files at > user/ports//portbase/ but evidently not. What is the easiest way to > find out, sitting in console on a server without a GUI, to find out who the > maintainer is? (On my desktop I can just google and launch a browser, but > that is not possible on most of the servers which do not have web clients > installed. > > (Right now I am looking for the maintainer of roundcube, but this is a > general question.) > > man pkg-info or grep -i maintainer /path/to/port/Makefile -- Steve ___ 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"
Re: Using a different linker in a CMake project
On Thu, Sep 26, 2019 at 06:18:17PM +0200, Willem Jan Withagen wrote:
>
> For building ceph14 in I need to use ld from the ports binutils.
> Mainly because of versioning that I can not get to work with the llvm
> linker, and is a know difference between GNU ld en LLVM ld.
>
> Just building in the project I was able to do that with:
>-D CMAKE_CXX_FLAGS_DEBUG=" -fuse-ld=/usr/local/bin/ld
> -Wno-unused-command-line-argument"
>
> So I'm trying to pass that also in the ports Makefile as a CMAKE_ARGS.
> But nothing thusfar I've tried does actually work. and gets the option
> on the commandline.
>
> So is there a way to get this to work.
> It is sort of tricky since CMAKE output uses cc of c++ to do linking.
>
> A brute force hack would be to
> rm /usr/bin/ld
> ln -s /usr/local/bin/ld /usr/bin/ld
> But I sure that that would not make it in the porst tree.
>
% cat Makefile
PATH = /usr/bin:/bin
.unexport-env
.export PATH
all:
@echo ${PATH}
which ld
% which ld
/usr/local/bin/ld
% make
/usr/bin:/bin
which ld
/usr/bin/ld
HTH
--
Steve
___
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"
Re: ports/lang major version updates outside of OS version updates
On Sat, Apr 13, 2019 at 10:59:41PM +0200, Dima Pasechnik wrote: > On Sat, Apr 13, 2019 at 10:41 PM Steve Kargl > > > > How about taking the patch in my previous email, apply > > to your tree (any port committer can take the patch), > > and actually commit it! > > > > This isn't rocket science. APPLY THE PATCH AND COMMIT! > > I don't have commit access to python FreeBSD port (or any port, in fact). > --- if I had said access it would have been done months ago... > There is nothing you can do :( I have jsut sent an email to freebsd-core requesting that I have be commit bit restored. I will commit my sinpi implementation. This will break lang/python27, lang/python35, and lang/python36, and by extension all ports that depend on one of these ports. It will hopefully mobilize someone from python@freebsd to act. -- Steve ___ 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"
Re: ports/lang major version updates outside of OS version updates
On Sat, Apr 13, 2019 at 08:49:43PM +0200, Dima Pasechnik wrote: > On Sat, Apr 13, 2019 at 8:01 PM Steve Kargl > > > > My patches have absolutely nothing to do with making > > 3.6 the default python version. > > > > I have added functions to libm that are included in > > two ISO standards. This causes a name conflict with > > sinpi() in python. My patches trivially rename > > python's sinpi() to avoid the conflict. For some reason > > beyond the comprehension of mortal man, python@freebsd > > refuses to add the patches to the port. > > they asked for these patches to be upstreamed, and I did it, so these > patches now are in not yet released upstream python 2 and python 3 > branches. > Backporting them to python@freebsd is totally trivial. > > What else can be done here? How about taking the patch in my previous email, apply to your tree (any port committer can take the patch), and actually commit it! This isn't rocket science. APPLY THE PATCH AND COMMIT! -- Steve ___ 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"
Re: ports/lang major version updates outside of OS version updates
On Sat, Apr 13, 2019 at 07:35:25AM -0700, Roger Marquis wrote: > >> On Fri, Apr 12, 2019 at 11:18:50PM +0200, Dima Pasechnik wrote: > >>> So there is more "software bureaucracy" here than just applying one patch. > > You sure about that Dima? Whether one or several the patching doesn't > appear to be complicated or difficult to maintain. > > > On Fri, Apr 12, 2019 at 02:58:22PM -0700, Steve Kargl wrote: > > For those people following along in the mailing list, Dima > > sent me a private reply that took this thread off the list. > > I am done trying to help fix the python ports. > > Thanks for the good work Steve. > > Many of us are still wondering why this change was made outside of a > major OS version update. Wouldn't that have prevented the build bug > which started this thread? > > Considering the incompatibilities between python 2.X and 3.x (which > Guido has admitted was a mistake) please consider this a ports policy > request to require significant lang/* version updates be predicated on > equally significant OS version updates. > My patches have absolutely nothing to do with making 3.6 the default python version. I have added functions to libm that are included in two ISO standards. This causes a name conflict with sinpi() in python. My patches trivially rename python's sinpi() to avoid the conflict. For some reason beyond the comprehension of mortal man, python@freebsd refuses to add the patches to the port. -- Steve ___ 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"
Re: Default python is 3.6?
On Fri, Apr 12, 2019 at 02:58:22PM -0700, Steve Kargl wrote: > On Fri, Apr 12, 2019 at 11:18:50PM +0200, Dima Pasechnik wrote: > > > > So there is more "software bureaucracy" here than just applying one patch. > > > > % cd /usr/ports/lang > % svn status > A python27/files/patch-Modules___mathmodule.c > A python35/files/patch-Modules___mathmodule.c > A python36/files/patch-Modules___mathmodule.c > % svn diff python27/files/patch-Modules___mathmodule.c \ >python35/files/patch-Modules___mathmodule.c \ >python36/files/patch-Modules___mathmodule.c > py.diff > % cat py.diff For those people following along in the mailing list, Dima sent me a private reply that took this thread off the list. I am done trying to help fix the python ports. -- Steve ___ 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"
Re: Python conflict on RPI2
On Fri, Apr 12, 2019 at 09:47:54PM -0700, bob prohaska wrote: > > Is there any hope of simply replacing python27 with python36? The > goal at hand is merely to compile a working version of firefox. > In general, no. Python 2.7 and 3.6 are incompatible. -- Steve ___ 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"
Re: Python conflict on RPI2
On Fri, Apr 12, 2019 at 06:45:41PM -0700, bob prohaska wrote: > In tinkering with compiling firefox on an RPI2 attempts to use > portmaster fail with > > ===> Registering installation for py36-setuptools-40.8.0_1 > Installing py36-setuptools-40.8.0_1... > pkg-static: py36-setuptools-40.8.0_1 conflicts with py27-setuptools-40.8.0 > (installs files into the same place). Problematic file: > /usr/local/bin/easy_install > *** Error code 70 > > I've tried things like deleting the problematic file, and compiling python36 > separately, to no effect. What else is worth trying? > > Thanks for reading, > > bob prohaska > pkg info | grep py > py.txt pkg delete -f py27-setuptools-40.8.0 install 3.6 re-install python27 -- Steve ___ 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"
Re: Default python is 3.6?
On Fri, Apr 12, 2019 at 11:18:50PM +0200, Dima Pasechnik wrote:
>
> So there is more "software bureaucracy" here than just applying one patch.
>
% cd /usr/ports/lang
% svn status
A python27/files/patch-Modules___mathmodule.c
A python35/files/patch-Modules___mathmodule.c
A python36/files/patch-Modules___mathmodule.c
% svn diff python27/files/patch-Modules___mathmodule.c \
python35/files/patch-Modules___mathmodule.c \
python36/files/patch-Modules___mathmodule.c > py.diff
% cat py.diff
Index: python27/files/patch-Modules___mathmodule.c
===
--- python27/files/patch-Modules___mathmodule.c (nonexistent)
+++ python27/files/patch-Modules___mathmodule.c (working copy)
@@ -0,0 +1,38 @@
+--- ./Modules/mathmodule.c.orig2019-04-12 10:00:28.51846 -0700
./Modules/mathmodule.c 2019-04-12 10:01:24.846412000 -0700
+@@ -71,7 +71,7 @@
+ static const double sqrtpi = 1.772453850905516027298167483341145182798;
+
+ static double
+-sinpi(double x)
++_freebsd_ports_are_broken_sinpi(double x)
+ {
+ double y, r;
+ int n;
+@@ -270,7 +270,7 @@
+integer. */
+ if (absx > 200.0) {
+ if (x < 0.0) {
+-return 0.0/sinpi(x);
++return 0.0/_freebsd_ports_are_broken_sinpi(x);
+ }
+ else {
+ errno = ERANGE;
+@@ -294,7 +294,7 @@
+ }
+ z = z * lanczos_g / y;
+ if (x < 0.0) {
+-r = -pi / sinpi(absx) / absx * exp(y) / lanczos_sum(absx);
++r = -pi / _freebsd_ports_are_broken_sinpi(absx) / absx * exp(y) /
lanczos_sum(absx);
+ r -= z * r;
+ if (absx < 140.0) {
+ r /= pow(y, absx - 0.5);
+@@ -366,7 +366,7 @@
+ (x-0.5)*(log(x+lanczos_g-0.5)-1);
+ }
+ else {
+-r = log(pi) - log(fabs(sinpi(absx))) - log(absx) -
++r = log(pi) - log(fabs(_freebsd_ports_are_broken_sinpi(absx))) -
log(absx) -
+ (log(lanczos_sum(absx)) - lanczos_g +
+ (absx-0.5)*(log(absx+lanczos_g-0.5)-1));
+ }
Index: python35/files/patch-Modules___mathmodule.c
===
--- python35/files/patch-Modules___mathmodule.c (nonexistent)
+++ python35/files/patch-Modules___mathmodule.c (working copy)
@@ -0,0 +1,38 @@
+--- ./Modules/mathmodule.c.orig2019-04-12 14:35:01.873406000 -0700
./Modules/mathmodule.c 2019-04-12 14:35:42.751667000 -0700
+@@ -67,7 +67,7 @@
+ static const double logpi = 1.144729885849400174143427351353058711647;
+
+ static double
+-sinpi(double x)
++_freebsd_ports_are_broken_sinpi(double x)
+ {
+ double y, r;
+ int n;
+@@ -296,7 +296,7 @@
+integer. */
+ if (absx > 200.0) {
+ if (x < 0.0) {
+-return 0.0/sinpi(x);
++return 0.0/_freebsd_ports_are_broken_sinpi(x);
+ }
+ else {
+ errno = ERANGE;
+@@ -320,7 +320,7 @@
+ }
+ z = z * lanczos_g / y;
+ if (x < 0.0) {
+-r = -pi / sinpi(absx) / absx * exp(y) / lanczos_sum(absx);
++r = -pi / _freebsd_ports_are_broken_sinpi(absx) / absx * exp(y) /
lanczos_sum(absx);
+ r -= z * r;
+ if (absx < 140.0) {
+ r /= pow(y, absx - 0.5);
+@@ -390,7 +390,7 @@
+ r += (absx - 0.5) * (log(absx + lanczos_g - 0.5) - 1);
+ if (x < 0.0)
+ /* Use reflection formula to get value for negative x. */
+-r = logpi - log(fabs(sinpi(absx))) - log(absx) - r;
++r = logpi - log(fabs(_freebsd_ports_are_broken_sinpi(absx))) -
log(absx) - r;
+ if (Py_IS_INFINITY(r))
+ errno = ERANGE;
+ return r;
Index: python36/files/patch-Modules___mathmodule.c
===
--- python36/files/patch-Modules___mathmodule.c (nonexistent)
+++ python36/files/patch-Modules___mathmodule.c (working copy)
@@ -0,0 +1,38 @@
+--- ./Modules/mathmodule.c.orig2019-04-12 09:23:42.32935 -0700
./Modules/mathmodule.c 2019-04-12 09:24:37.977029000 -0700
+@@ -67,7 +67,7 @@
+ static const double logpi = 1.144729885849400174143427351353058711647;
+
+ static double
+-sinpi(double x)
++_freebsd_port_are_broken_sinpi(double x)
+ {
+ double y, r;
+ int n;
+@@ -296,7 +296,7 @@
+integer. */
+ if (absx > 200.0) {
+ if (x < 0.0) {
+-return 0.0/sinpi(x);
++return 0.0/_freebsd_port_are_broken_sinpi(x);
+ }
+ else {
+ errno = ERANGE;
+@@ -320,7 +320,7 @@
+ }
+ z = z * lanczos_g / y;
+ if (x < 0.0) {
+-r = -pi / sinpi(absx) / absx * exp(y) / lanczos_sum(absx);
++r = -pi / _freebsd_port_are_broken_sinpi(absx) / absx * exp(y) /
lanczos_sum(absx);
+ r -= z * r;
+ if (absx < 140.0) {
+ r /= pow(y, absx - 0.5);
+@@ -390,7 +390,7 @@
+ r += (absx - 0.5) * (log(absx + lanczos_g - 0.5) - 1);
+ if (x < 0.0)
+ /* Use reflection
Re: Default python is 3.6?
On Fri, Apr 12, 2019 at 10:14:19PM +0200, Dima Pasechnik wrote: > On Fri, Apr 12, 2019 at 9:57 PM Steve Kargl > > > > Doesn't matter what the python developer have done. > > Thanks, I see that you really appreciate my work... > Your work is appreciated as much as my last 3 years of efforts to get a trivially stupid patch acknowledged by python@freebsd. Why is it so harder for python@freebsd to do svn add files/patch-Modules___mathmodule.c svn commit files/patch-Modules___mathmodule.c ? -- Steve ___ 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"
Re: Default python is 3.6?
On Fri, Apr 12, 2019 at 09:19:30PM +0200, Dima Pasechnik wrote:
> On Fri, Apr 12, 2019 at 6:29 PM Steve Kargl
> wrote:
> >
> > On Fri, Apr 12, 2019 at 09:17:42AM -0700, Steve Kargl wrote:
> > >
> > > % find . -name math\*
> > > ./work/Python-3.6.8/Doc/library/math.rst
> > > ./work/Python-3.6.8/Modules/mathmodule.c
> > > ./work/Python-3.6.8/Lib/test/math_testcases.txt
> > > ./work/stage/usr/local/lib/python3.6/test/math_testcases.txt
> > >
> >
> > Well, this one is easy to fix. I've sent this patch for 2 to 3
> > years now. I've opened a PR about it. Someday you guys might
> > actually fix this, because I will contacting core to get my
> > commit bit back.
> >
> This one is fixed in Python 3.7:
> https://github.com/python/cpython/blob/3.7/Modules/mathmodule.c
> via this commit:
> https://github.com/python/cpython/commit/4e6646fef5d2cc53422e4eca0b18201ed5a5c4b6
>
> It is also fixed in Python 2.7.
> See https://github.com/python/cpython/pull/12027 for details.
Doesn't matter what the python developer have done. A patch is
still required to build lang/python27. Here's yet another
copy of the patch.
--- ./Modules/mathmodule.c.orig 2019-04-12 10:00:28.51846 -0700
+++ ./Modules/mathmodule.c 2019-04-12 10:01:24.846412000 -0700
@@ -71,7 +71,7 @@
static const double sqrtpi = 1.772453850905516027298167483341145182798;
static double
-sinpi(double x)
+_freebsd_ports_are_broken_sinpi(double x)
{
double y, r;
int n;
@@ -270,7 +270,7 @@
integer. */
if (absx > 200.0) {
if (x < 0.0) {
-return 0.0/sinpi(x);
+return 0.0/_freebsd_ports_are_broken_sinpi(x);
}
else {
errno = ERANGE;
@@ -294,7 +294,7 @@
}
z = z * lanczos_g / y;
if (x < 0.0) {
-r = -pi / sinpi(absx) / absx * exp(y) / lanczos_sum(absx);
+r = -pi / _freebsd_ports_are_broken_sinpi(absx) / absx * exp(y) /
lanczos_sum(absx);
r -= z * r;
if (absx < 140.0) {
r /= pow(y, absx - 0.5);
@@ -366,7 +366,7 @@
(x-0.5)*(log(x+lanczos_g-0.5)-1);
}
else {
-r = log(pi) - log(fabs(sinpi(absx))) - log(absx) -
+r = log(pi) - log(fabs(_freebsd_ports_are_broken_sinpi(absx))) -
log(absx) -
(log(lanczos_sum(absx)) - lanczos_g +
(absx-0.5)*(log(absx+lanczos_g-0.5)-1));
}
--
Steve
___
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"
Re: Default python is 3.6?
On Fri, Apr 12, 2019 at 09:17:42AM -0700, Steve Kargl wrote:
>
> % find . -name math\*
> ./work/Python-3.6.8/Doc/library/math.rst
> ./work/Python-3.6.8/Modules/mathmodule.c
> ./work/Python-3.6.8/Lib/test/math_testcases.txt
> ./work/stage/usr/local/lib/python3.6/test/math_testcases.txt
>
Well, this one is easy to fix. I've sent this patch for 2 to 3
years now. I've opened a PR about it. Someday you guys might
actually fix this, because I will contacting core to get my
commit bit back.
--- work/Python-3.6.8/Modules/mathmodule.c.orig 2019-04-12 09:23:42.32935
-0700
+++ work/Python-3.6.8/Modules/mathmodule.c 2019-04-12 09:24:37.977029000
-0700
@@ -67,7 +67,7 @@
static const double logpi = 1.144729885849400174143427351353058711647;
static double
-sinpi(double x)
+_freebsd_ports_are_broken_sinpi(double x)
{
double y, r;
int n;
@@ -296,7 +296,7 @@
integer. */
if (absx > 200.0) {
if (x < 0.0) {
-return 0.0/sinpi(x);
+return 0.0/_freebsd_ports_are_broken_sinpi(x);
}
else {
errno = ERANGE;
@@ -320,7 +320,7 @@
}
z = z * lanczos_g / y;
if (x < 0.0) {
-r = -pi / sinpi(absx) / absx * exp(y) / lanczos_sum(absx);
+r = -pi / _freebsd_ports_are_broken_sinpi(absx) / absx * exp(y) /
lanczos_sum(absx);
r -= z * r;
if (absx < 140.0) {
r /= pow(y, absx - 0.5);
@@ -390,7 +390,7 @@
r += (absx - 0.5) * (log(absx + lanczos_g - 0.5) - 1);
if (x < 0.0)
/* Use reflection formula to get value for negative x. */
-r = logpi - log(fabs(sinpi(absx))) - log(absx) - r;
+r = logpi - log(fabs(_freebsd_ports_are_broken_sinpi(absx))) -
log(absx) - r;
if (Py_IS_INFINITY(r))
errno = ERANGE;
return r;
--
Steve
___
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"
Re: Default python is 3.6?
On Fri, Apr 12, 2019 at 09:11:12AM -0700, Steve Kargl wrote: > cd /usr/ports/lang/python36 > make && make install > > ===> Installing for python36-3.6.8_2 > ===> Checking if python36 is already installed > ===> Registering installation for python36-3.6.8_2 > pkg-static: Unable to access file > /usr/ports/lang/python36/work/stage/usr/local/lib/python3.6/lib-dynload/_asyncio.so:No > such file or directory > pkg-static: Unable to access file > /usr/ports/lang/python36/work/stage/usr/local/lib/python3.6/lib-dynload/math.so:No > such file or directory > *** Error code 74 > > Stop. > make[1]: stopped in /usr/ports/lang/python36 > *** Error code 1 > > Stop. > make: stopped in /usr/ports/lang/python36 > > ? > % find . -name _async\* ./work/Python-3.6.8/Modules/_asynciomodule.c ./work/Python-3.6.8/Modules/clinic/_asynciomodule.c.h ./work/Python-3.6.8/PCbuild/_asyncio.vcxproj.filters ./work/Python-3.6.8/PCbuild/_asyncio.vcxproj ./work/Python-3.6.8/build/lib.freebsd-13.0-CURRENT-amd64-3.6/_asyncio_failed.so ./work/Python-3.6.8/build/temp.freebsd-13.0-CURRENT-amd64-3.6/usr/ports/lang/python36/work/Python-3.6.8/Modules/_asynciomodule.o ./work/stage/usr/local/lib/python3.6/lib-dynload/_asyncio_failed.so % find . -name math\* ./work/Python-3.6.8/Doc/library/math.rst ./work/Python-3.6.8/Modules/mathmodule.c ./work/Python-3.6.8/Lib/test/math_testcases.txt ./work/stage/usr/local/lib/python3.6/test/math_testcases.txt ? -- Steve ___ 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"
Default python is 3.6?
cd /usr/ports/lang/python36 make && make install ===> Installing for python36-3.6.8_2 ===> Checking if python36 is already installed ===> Registering installation for python36-3.6.8_2 pkg-static: Unable to access file /usr/ports/lang/python36/work/stage/usr/local/lib/python3.6/lib-dynload/_asyncio.so:No such file or directory pkg-static: Unable to access file /usr/ports/lang/python36/work/stage/usr/local/lib/python3.6/lib-dynload/math.so:No such file or directory *** Error code 74 Stop. make[1]: stopped in /usr/ports/lang/python36 *** Error code 1 Stop. make: stopped in /usr/ports/lang/python36 ? -- Steve ___ 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"
Re: "libicuuc.so.61" not found, required by "libephymisc.so" on RPi2
On Fri, Apr 12, 2019 at 08:32:57AM -0700, bob prohaska wrote: > Can anybody tell me how to fix an error reported by www/epiphany on an RPi2, > "libicuuc.so.61" not found, required by "libephymisc.so" with the system > at 11.2-STABLE #2 r345473 and ports at 498696 ? > > Both epiphany and icu are up to date, there was no deliberate deletion > of old libraries but apparently it happened anyway. > > Thank for reading, and any guidance! > % cat /etc/libmap.conf includedir /usr/local/etc/libmap.d libicudata.so.63 libicudata.so.64 libicui18n.so.63 libicui18n.so.64 libicuio.so.63 libicuio.so.64 libicutu.so.63 libicutu.so.64 libicuuc.so.63 libicuuc.so.64 Choose your numbers accordingly. -- Steve ___ 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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Mon, Feb 25, 2019 at 01:58:01AM +, Dima Pasechnik wrote: > On Sun, Feb 24, 2019 at 8:09 PM Steve Kargl > > > 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 :-)) > And, I would tell you to read the 3 or 4 emails I sent to the various mailing list and the PR. TS 18661-4 I should ask for my commit bit back, and commit the sinpi patch just to spite people like you who spout off without actually looking at what people give you. -- Steve ___ 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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
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 +, 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 ___ 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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
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? > Dave, 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. -- Steve ___ 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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, Feb 22, 2019 at 07:09:11PM +0200, Konstantin Belousov wrote: > On Fri, Feb 22, 2019 at 08:44:54AM -0800, Steve Kargl wrote: > > > > Because FreeBSD usurped the name of a well-known library from a > > well-known open source project. Users might expect that that > > well-known library has the same ABI and functionality of the > > library provided by the well-known project. > Nothing was usurped, you can lower your tone. > > Initially libgcc_s.so.1 was provided by gcc and the library was updated > during the regular gcc imports. When gcc changed the license, the > libgcc_s.so.1 become stalled due to the block on the import of the new > gcc versions. I know the history. When FreeBSD decided to move away from gcc, then it should move away. That includes either removing libgcc_s.so or renaming it. As it is now, FreeBSD libgcc_s.so does not provide the ABI in the official libgcc_s.so as distributed with any version of gcc newer than gcc=4.5.z. It clearly is causing problems. Yes, I know some oddball architectures cannot (or at least could not) be compiled with clang/llvm, so contrib/gcc remains in the tree. In these special cases, then libgcc_s.so can be installed as part of installing contrib/gcc. > Some parts of gcc-provided libgcc_s.so.1 were replaced with llvm unwinder, > some parts with compiler-rt functions. The new functions added by gcc > were not imported because nobody who can do that knew about the problem. > Generic hand-waving is not the problem description. > > Now, that the list of missing symbols is collected and possible sources > for them are identified, at least some gaps can be filled. > > > > > If nothing in base needs /lib/libgcc_s, then let's remove it. > > If nothing in base needs it, let's rename name it to libfreebsd_s.so. > This cannot be done, because it breaks the base system ABI. In > particular, after that almost all compiled C++ apps will be broken, and > significant amount of threaded programs as well. Then the assertion that nothing in base needs libgcc_s.so is wrong? And, yes, if an application is currently using /lib/libgcc_s.so, then it would need to be recompiled. When it is recompiled, it can use libcompiler_rt or, if need be, it can use the libgcc_s.so provided by a gcc port. -- Steve ___ 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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, Feb 22, 2019 at 05:11:20PM +0100, Tijl Coosemans wrote: > On Thu, 21 Feb 2019 10:24:51 -0800 Steve Kargl > > > BTW, if you compare gcc trunks symbol map > > ./x86_64-unknown-freebsd13.0/libgcc/libgcc.map > > with src/lib/libgcc_s/Version.map, you'll find that > > that maps are no one-to-one. > > Yes, libgcc_s implements stack unwinding and exception handling and > libgcc.a does not. The stack unwinding and exception handling code has > to be shared so all code in a process uses the same implementation and > accompanying data structures. The above map files are for libgcc_s.so. Yes, the name for the in-tree map file for libgcc_s.so is libgcc.map. -- Steve ___ 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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote: > On Fri, 22 Feb 2019 15:39:17 +0200 Konstantin Belousov > wrote: > > Yes, we absolutely must avoid situation where two similar libraries > > (i.e. providing some subset of symbols from other) are linked into the > > same executing process. > > > > I think your patches would be a definitive improvement, esp. the part > > which makes libgfortran linking only as needed. > > > > For the other part, which makes the ports dso a priority over the base > > dso, I would exercise some more causion. For ports we know only about > > libgcc_s.so.1 which has the same name in base and in ports, other > > libraries in base should have libprivate suffix to not conflict, right ? > > What about openssl libraries ? > > As long as libraries have a different name the search order in the > ldconfig cache doesn't matter. So libfoo.so.x and libprivatefoo.so.x > don't conflict but neither do libfoo.so.x and libfoo.so.y. Some > libraries in base have the libprivate prefix and they are not meant to > be used by ports at all. The openssl libraries in base have a different > version suffix than security/openssl* and are allowed to be used by > ports. > > > I think such setup makes it easier for user to accidentaly break the system. > > She could install something manually (not from ports), or copy some file > > into /usr/local/lib, which conflicts with base and cause troubles. > > Or they could copy something in /lib or /usr/lib and break their system. > > The idea behind the ldconfig patch is that the runtime search order > should be as close as possible to a typical compile time order. > Typically compilers and linkers search /usr/local before /usr, so > ldconfig should search /usr/local before /usr. Anyone that wants a > different order needs to provide a good explanation for that and I don't > think protecting users from shooting themselves in the foot is a good > enough reason. > > Similarly, I think our default PATH is also backwards. Major Linux > distros and MacOS all put /usr/local/bin before /usr/bin. > > # User can override sysadmin who can override OS: > PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin > > > Do you agree that the ultimate and proper solution is to add missed symbols > > and versions to the base libgcc_s.so.1 ? IMO it is, and this thread started > > to show some work which might finally solve that. > > (But about as-needed for libgfortran see above). > > Not really no: > > 1) GCC can add new symbols or new versions of them with every release > which means the problem can reappear with every new GCC release and GCC > releases aren't aligned with FreeBSD releases. GCC developers do add new symbols. Not sure what you mean by new versions. The ABI is stable. If they change the ABI, then they would bump the major number to 2. > 2) Base system libgcc is essentially libcompilerrt, the LLVM compiler > runtime. LLVM doesn't seem to need these symbols, nothing in base needs > these symbols so why should we implement these third party compiler > runtime helper functions? Because FreeBSD usurped the name of a well-known library from a well-known open source project. Users might expect that that well-known library has the same ABI and functionality of the library provided by the well-known project. If nothing in base needs /lib/libgcc_s, then let's remove it. If nothing in base needs it, let's rename name it to libfreebsd_s.so. > 3) With my gfortran patch you don't need to implement anything. It's an > apply-once-and-stop-worrying-about-it solution for all versions of FreeBSD. Your patching a gfortran spec file. Don't you need to worry about the spec file changing, which may invalidate your patch? -- Steve ___ 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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, Feb 22, 2019 at 12:28:41PM +0100, Tijl Coosemans wrote: > > PS: For the record, the GCC_4.6.0 are needed for gfortran REAL(16) > > type. > > With my patch gfortran resolves the GCC_4.6.0 symbols statically just > like the C compilers do. If the C compilers didn't do this we'd have > this libgcc_s problem all over the place. It makes perfect sense to > make gfortran do the same thing. I'm fine with your patch. -- Steve ___ 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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Fri, Feb 22, 2019 at 09:32:03AM -0500, Ed Maste wrote:
> On Thu, 21 Feb 2019 at 16:47, Steve Kargl
> wrote:
> >
> > The missing symbols are
> >
> > % objdump -x lib/libgfortran.so | grep GCC_4.6.0 | awk '{print $5}' | sort
>
> Thank you for collecting these.
>
> > It looks like we may be able to grab some of these from libc/softfloat:
> > getf2.c, gttf2.c, letf2.c, lttf2.c, netf2.c.
> >
> > It looks like we might be able to grab a few more from NetBSD:
> > eqtf2.c and unordtf2.c
>
> All seven of these are available in compiler-rt, I believe they just
> need to be built and added to the version map.
>
> That leaves: __addtf3 __divtf3 __floatditf __floatsitf __floatunditf
> __multf3 __subtf3
>
> compiler-rt also has these, but provided only in this case:
> #if defined(CRT_HAS_128BIT) && defined(CRT_LDBL_128BIT)
gfortran provides a REAL(16) type, which is an implementation
of IEEE 754 binary128. If the architecture has a 128-bit float
type such as sparc64, there isn't a problem. If the 128-bit
is available from the architecture such as i386, then it uses
GCC __float128 software implementation. If compiler-rt has
these functions, are they compatiable with GCC's __float128.
--
Steve
___
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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, Feb 21, 2019 at 11:18:50PM +0100, Tijl Coosemans wrote: > On Thu, 21 Feb 2019 13:30:41 -0500 Diane Bruce wrote: > > On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote: > >> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote: > >>> Except python doesn't have an rpath which is why this keeps coming > >>> up over and over again. > >> > >> Maybe we should just add the gcc rpaths to the python ports LDFLAGS > >> without depending on gcc. Then python should use gcc libgcc_s when > >> it exists and fall back to base system libgcc_s when it doesn't. > > > > Right. Or just provide a shell shim to LD_PRELOAD IFF it is noticed > > a specific port will require a fortran built binary module later. > > > >> Maybe we should compile *all* ports with gcc rpaths without depending > >> on gcc, just like we already compile everything with -fstack-protector > >> in LDFLAGS. > >> > >> There's also the fact that gfortran behaves differently from the C > >> compilers (both clang and gcc) when it comes to libgcc_s. Gfortran > >> always links with libgcc_s. The C compilers link with libgcc.a first > >> and then with libgcc_s only as needed. This eliminates almost all > > > > What is really happening is gfortran links with libgfortran (surprise > > surprise) and libgfortran has the requirement for @GCC_4.6.0 or later > > > >> links with libgcc_s. The only ones left are for exception handling > >> and stack unwinding and gcc libgcc_s and base system libgcc_s are > >> version compatible for that so it doesn't matter which one gets picked > >> up. The attached patch for lang/gcc8 makes gfortran behave just like > >> the C compilers. > > > > Something like this was tried already. I'll have to dig into > > my old notes. > > With my patch libgfortran only needs GCC_4.2.0 and works with base > libgcc_s. Why not bump the major version number of the port? % svn diff libgcc/ Index: libgcc/config/t-slibgcc === --- libgcc/config/t-slibgcc (revision 269077) +++ libgcc/config/t-slibgcc (working copy) @@ -20,7 +20,7 @@ SHLIB_EXT = .so SHLIB_SOLINK = @shlib_base_name@.so -SHLIB_SOVERSION = 1 +SHLIB_SOVERSION = 2 SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION) SHLIB_MAP = @shlib_map_file@ SHLIB_OBJS = @shlib_objs@ Assuming the port system runs ldconfig to update the cache, one has % ~/work/x/bin/gfortran -o z hello.f90 % ldd z z: libgfortran.so.5 => /usr/local/lib/gcc8/libgfortran.so.5 (0x20080) libm.so.5 => /lib/libm.so.5 (0x200645000) libgcc_s.so.2 => /safe/sgk/work/x/lib/libgcc_s.so.2 (0x200c58000) libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x200e7) libc.so.7 => /lib/libc.so.7 (0x2010b) libz.so.6 => /lib/libz.so.6 (0x200678000) libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x2014a1000) % nm z | grep 4.6 U __multf3@@GCC_4.6.0 % ./z 2.000 Note, I'm playing with a test install into a ~/work/x directory. The ldconfig still has issues with first come first served % ldconfig -r | grep libgcc_s 6:-lgcc_s.1 => /lib/libgcc_s.so.1 806:-lgcc_s.1 => /usr/local/lib/gcc8/libgcc_s.so.1 880:-lgcc_s.2 => /safe/sgk/work/x/lib/libgcc_s.so.2 % ldconfig -r | grep libgfortran 808:-lgfortran.5 => /usr/local/lib/gcc8/libgfortran.so.5 876:-lgfortran.5 => /safe/sgk/work/x/lib/libgfortran.so.5 6 is picked up due to libc.so. 806 is picked up due to 808, but won't be there is major version number is bumped. 876 is the loser of the first come first served, here; but 808 would be the correct libgfortran point to 880 if I had installed into /usr/local/lib/gcc8. PS: For the record, the GCC_4.6.0 are needed for gfortran REAL(16) type. -- Steve ___ 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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, Feb 21, 2019 at 01:30:41PM -0500, Diane Bruce wrote:
>
> Yes yes and yes. It would be a right PITA. Perhaps it could be done
> with some weak symbols but personally I think that's another hack.
> I'll go look for whatever symbols we are missing and see if we
> can fix our libgcc_s
>
Diane,
The missing symbols are
% objdump -x lib/libgfortran.so | grep GCC_4.6.0 | awk '{print $5}' | sort
__addtf3@@GCC_4.6.0
__divtf3@@GCC_4.6.0
__eqtf2@@GCC_4.6.0
__floatditf@@GCC_4.6.0
__floatsitf@@GCC_4.6.0
__floatunditf@@GCC_4.6.0
__getf2@@GCC_4.6.0
__gttf2@@GCC_4.6.0
__letf2@@GCC_4.6.0
__lttf2@@GCC_4.6.0
__multf3@@GCC_4.6.0
__netf2@@GCC_4.6.0
__subtf3@@GCC_4.6.0
__unordtf2@@GCC_4.6.0
It looks like we may be able to grab some of these from libc/softfloat:
getf2.c, gttf2.c, letf2.c, lttf2.c, netf2.c.
It looks like we might be able to grab a few more from NetBSD:
eqtf2.c and unordtf2.c
--
steve
___
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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, Feb 21, 2019 at 10:24:51AM -0800, Steve Kargl wrote:
>
> As anyone tried adding an empty sections to FreeBSD's
> libgcc_s,
>
> /*
> * Empty sections to work around FreeBSD abusing the name
> * of a well-known GCC library.
> */
> GCC_4.6.0 {
>
> } GCC_4.3.0;
>
> GCC_4.7.0 {
>
> } GCC_4.6.0;
>
> GCC_4.8.0 {
>
> } GCC_4.7.0;
>
> GCC_7.0.0 {
>
> } GCC_4.8.0;
>
Interesting. The above does put symbols into libgcc_s.so,
% objdump -x /usr/obj/usr/src/amd64.amd64/lib/libgcc_s/libgcc_s.so | more
...
1 0x01 0x04bd5c11 libgcc_s.so.1
2 0x00 0x0b792650 GCC_3.0
3 0x00 0x0b792653 GCC_3.3
4 0x00 0x09265f61 GCC_3.3.1
5 0x00 0x0b792654 GCC_3.4
6 0x00 0x09265e62 GCC_3.4.2
7 0x00 0x09265e64 GCC_3.4.4
8 0x00 0x09275a60 GCC_4.0.0
9 0x00 0x09276060 GCC_4.2.0
10 0x00 0x09275f60 GCC_4.3.0
11 0x00 0x09275460 GCC_4.6.0
12 0x00 0x09275360 GCC_4.7.0
13 0x00 0x09275260 GCC_4.8.0
14 0x00 0x092a5a60 GCC_7.0.0
whether the symbols added to GCC_4.6.0, 4.7.0, 4.8.0, and 7.0.0
are needed remains to been seen.
--
Steve
___
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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, Feb 21, 2019 at 10:53:00AM -0700, Russell L. Carter wrote: > On 2/21/19 10:05 AM, Tijl Coosemans wrote: > > On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote: > >> On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote: > >>> So I must dig deeper. Perhaps with rpaths interacting with the system > >>> paths? > >> > >> You got it. ;) > >> Except python doesn't have an rpath which is why this keeps coming > >> up over and over again. > > > > Maybe we should just add the gcc rpaths to the python ports LDFLAGS > > without depending on gcc. Then python should use gcc libgcc_s when > > it exists and fall back to base system libgcc_s when it doesn't. > > > > Maybe we should compile *all* ports with gcc rpaths without depending > > on gcc, just like we already compile everything with -fstack-protector > > in LDFLAGS. > > > > > I would like to briefly present the perspective from a user's POV. > There is a large world wide population of scientific custom code > users/coders who run on linux boxes in a wide variety of > configurations. Almost none of that code will ever have a chance of > ending up in /usr/ports, although there is nothing technically > challenging about almost any of it (the porting process that is). So > anytime any of those users wants to try running their non-ported > scientific code, a large fraction of which contains python and/or > gfortan code, they are going to hit the libgcc_s issue. Only a few of > those people understand rpaths as well as I do (and I'm no expert), > because it's never been their job. They probably struggle to figure > out what question to ask, because, "libgcc_s? WTF?, this is python!" > In addition, oftentimes people have sometimes big pipelines of > different programs executing. So writing a shell script wrapper > around each and every one of those custom programs... not going to > happen. libmap.conf(5)? Not going to happen. Linux works out of the > box. > > People like Steve Kargl and me are... puzzled at why FreeBSD would > do this to itself. Having people writing and running custom > opensource software on a performant opensource OS is **good**. We > should be enabling them. I'm not puzzled. I am amused! As a long time gfortran contributor and maintainer, and probably one of the few people who regularly builds and tests gfortran on FreeBSD, it is entertaining to see the emails about the issue. I particularly like the emails that suggest that this is a gfortran problem. It is not. -- Steve ___ 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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote:
> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce wrote:
> > On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote:
> >> So I must dig deeper. Perhaps with rpaths interacting with the system
> >> paths?
> >
> > You got it. ;)
> > Except python doesn't have an rpath which is why this keeps coming
> > up over and over again.
>
> Maybe we should just add the gcc rpaths to the python ports LDFLAGS
> without depending on gcc. Then python should use gcc libgcc_s when
> it exists and fall back to base system libgcc_s when it doesn't.
>
> Maybe we should compile *all* ports with gcc rpaths without depending
> on gcc, just like we already compile everything with -fstack-protector
> in LDFLAGS.
>
> There's also the fact that gfortran behaves differently from the C
> compilers (both clang and gcc) when it comes to libgcc_s. Gfortran
> always links with libgcc_s. The C compilers link with libgcc.a first
> and then with libgcc_s only as needed.
libgfortran is gfortran's runtime library. libgcc.a is gcc's
runtime library. The link orders are the same: libgfortran
then libgcc_s; libgcc then libgcc_s
> This eliminates almost all
> links with libgcc_s. The only ones left are for exception handling
> and stack unwinding and gcc libgcc_s and base system libgcc_s are
> version compatible for that so it doesn't matter which one gets picked
> up. The attached patch for lang/gcc8 makes gfortran behave just like
> the C compilers.
Just add -static to FFLAGS. Yep, you're building static
libraries.
> We cannot rename the base system libgcc_s to libclang_s because then a
> process could load both gcc libgcc_s and base system libclang_s and I
> think that could break exception handling and stack unwinding in weird
> ways.
Wouldn't that be a bug in the program that loads both?
BTW, if you compare gcc trunks symbol map
./x86_64-unknown-freebsd13.0/libgcc/libgcc.map
with src/lib/libgcc_s/Version.map, you'll find that
that maps are no one-to-one.
As anyone tried adding an empty sections to FreeBSD's
libgcc_s,
/*
* Empty sections to work around FreeBSD abusing the name
* of a well-known GCC library.
*/
GCC_4.6.0 {
} GCC_4.3.0;
GCC_4.7.0 {
} GCC_4.6.0;
GCC_4.8.0 {
} GCC_4.7.0;
GCC_7.0.0 {
} GCC_4.8.0;
--
Steve
___
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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 17, 2019 at 12:37:36PM +0700, Eugene Grosbein wrote: > 17.02.2019 12:11, Steve Kargl wrot: > > > > > There is a problem with the order of libgcc_s.so.1 > > in the cache created by ldconfig. rtld will use > > the first one it finds. If it fails, it fails. It > > does not look to see if there is a second entry. > > If binary needs specific version of libgcc_s.so.1 installed > with gcc8 port/package, then building system must use specific > rpath, so rtld would not use "the first one it finds". This is a well-known problem with libgcc_s.so.1 and gfortran. You can state whatever you believe should happen, but it does not seem to work that. You have a few options: 1) Add -static to your options; 2) Use LD_LIBRARY_PATH, LD_RUN_PATH to point to /usr/local/lib/gcc8; 3) Add -Wl,-rpath=/usr/local/lib/gcc8 to FFLAGS in /etc/make.conf (check syntax for this one); 4) bump the major library version number for /lib/libgcc.so.1 to 2; 5) fix rtld to not fail on the first found library in the cache. Iterated over all entries and only fail if the library isn't found; 6) rename /lib/libgcc_s.so.1 to /lib/libllvm_s.so.1 and teach llvm/clang/rtld to not misappropriate a well-known GCC library name. -- Steve ___ 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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 17, 2019 at 01:13:15PM +0700, Eugene Grosbein wrote:
> 17.02.2019 12:56, Steve Kargl wrote:
>
> >> 17.02.2019 12:11, Steve Kargl wrot:
> >>>
> >>> There is a problem with the order of libgcc_s.so.1
> >>> in the cache created by ldconfig. rtld will use
> >>> the first one it finds. If it fails, it fails. It
> >>> does not look to see if there is a second entry.
> >>
> >> If binary needs specific version of libgcc_s.so.1 installed
> >> with gcc8 port/package, then building system must use specific
> >> rpath, so rtld would not use "the first one it finds".
> >
> > This is a well-known problem with libgcc_s.so.1 and gfortran.
> > You can state whatever you believe should happen, but it does
> > not seem to work that. You have a few options:
> > 1) Add -static to your options;
> > 2) Use LD_LIBRARY_PATH, LD_RUN_PATH to point to
> >/usr/local/lib/gcc8;
> > 3) Add -Wl,-rpath=/usr/local/lib/gcc8 to FFLAGS in /etc/make.conf
> >(check syntax for this one);
> > 4) bump the major library version number for /lib/libgcc.so.1
> >to 2;
> > 5) fix rtld to not fail on the first found library in the cache.
> >Iterated over all entries and only fail if the library isn't found;
> > 6) rename /lib/libgcc_s.so.1 to /lib/libllvm_s.so.1 and teach
> >llvm/clang/rtld to not misappropriate a well-known GCC library
> >name.
> >
>
> When a port from our Ports Collection needs specific version of GCC and its
> runtime libraries,
> it utilizes "USE_GCC=8" and bsd.gcc.mk adds this to make everybody happy:
>
> CFLAGS+=-Wl,-rpath=${_GCC_RUNTIME}
> CXXFLAGS+= -Wl,-rpath=${_GCC_RUNTIME}
> LDFLAGS+= -Wl,-rpath=${_GCC_RUNTIME} -L${_GCC_RUNTIME}
>
> This is your 3) case and this is what I have meant.
FFLAGS+=
For whatever reason, there are situations where the rpath
isn't set in the library. Read the rtld manpage. You're
hitting #5 in the list.
--
Steve
___
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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 17, 2019 at 01:35:31PM +0700, Eugene Grosbein wrote: > 17.02.2019 13:19, Steve Kargl wrote: > > > For whatever reason, there are situations where the rpath > > isn't set in the library. Read the rtld manpage. You're > > hitting #5 in the list. > > Our package building system sets rpath for dependants of gcc8, > so Fortran libraries (and others) do have rpath for its runtime. > > Setting rpath for resulting binary should solve the problem. It seems that you may want to review the email archives. The issue with libgfortran.so and the wrong libgcc_s.so has come up about once a year for the last 5 to 10 years. -- Steve ___ 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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote: > > So I must dig deeper. Perhaps with rpaths interacting with the system > paths? > Read the rtld manpage. You're hitting #5 in the list, because the first 4 aren't satisified. Now, look at 'ldconfig -r | grep libgcc_s'. -- Steve ___ 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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 17, 2019 at 08:21:00AM +0700, Eugene Grosbein wrote: > > I've just did "pkg install gcc8" using my FreeBSD 11.2/amd64 system and got > this: > > # ldd /usr/local/lib/gcc8/libgfortran.so.5 > /usr/local/lib/gcc8/libgfortran.so.5: > libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x80146e000) > libz.so.6 => /lib/libz.so.6 (0x8016ad000) > libm.so.5 => /lib/libm.so.5 (0x8018c5000) > libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x801af3000) > libc.so.7 => /lib/libc.so.7 (0x800823000) > > So, /usr/local/lib/gcc8/libgfortran.so.5 does not depend on /lib/libgcc_s.so.1 > but on /usr/local/lib/gcc8/libgcc_s.so.1 in normal case. > > I assume something is broken in your installation. Try removing gcc8 and > reinstalling > it using package. > There is a problem with the order of libgcc_s.so.1 in the cache created by ldconfig. rtld will use the first one it finds. If it fails, it fails. It does not look to see if there is a second entry. -- Steve ___ 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"
Re: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sat, Feb 16, 2019 at 06:02:11PM -0700, Russell L. Carter wrote: > > /lib/libgcc_s.so.1 version GCC_4.8.0 required by > /usr/local/lib/gcc8/libgfortran.so.5 not found > > > Question to experienced porters, how is this best practice solved? > setenv LD_LIBRARY_PATH /usr/local/lib/gcc8 setenv LD_RUN_PATH /usr/local/lib/gcc8 -- Steve ___ 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"
Re: drm2 removed?
On Mon, Feb 11, 2019 at 08:20:20AM -0800, Steve Kargl wrote: > On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote: > > Anyone have any idea which recent change broke the > > drm-legacy-kmod port. This is why I raised an issue > > with removal of drm2 from src/sys. How is suppose > > to be fixed? > > > > It was r343567. The merging of PAE and NO PAE pmap.h > by kib removed all of the missing macros. :( > Waed the white flag. svn merge -r HEAD:343565 . fixes the problem. :-) -- Steve ___ 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"
Re: drm2 removed?
On Mon, Feb 11, 2019 at 06:42:29PM +0100, Niclas Zeising wrote: > > > > The patch allows the port to be built. > > > > kldloading the i915kms module causes a 'black screen > > of death' > > > Hi! > I assume you load the kernel module either manually with kldload or > using kld_list in rc.conf, not by loading it from the loader? > So there is two bugs? One bug is that the kernel hangs while booting, > and the other is that you get a black screen when loading the drm module > after the kernel is mostly done booting? > Things have gone sideways. Dumbed down CPUTYPE to pentiumpro for my Core2 duo. Spent all afternoon rebuilding kernel/world. Rebuilt the following ports with new world: drm-legacy-kmod-g20190109 gpu-firmware-kmod-g20181104 libXxf86vm-1.1.4_3 xf86-input-keyboard-1.9.0_3 xf86-input-mouse-1.9.3_2 xf86-video-intel-2.99.917.20181203 xf86-video-vesa-2.4.0_2 xorg-server-1.18.4_11,1 Load /boot/modules/i915kms.ko either manually or from rc.conf, results in a panic. The system didn't create a crash dump as I was expecting. A hand transcribed jpeg of panic screen Fatal trap 12: page fault while in kernel mode cpuid = 0: apic id = 00 fault virtual address = 0x8910 fault code = supervisor write data, page not present instruction pointer= 0x20:0xcc277a stack pointer = 0x28:0xa3cebd4 frame pointer = 0x28:0xa3cec20 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process= 0 (thread taskq) trap number= 12 panic: page fault cpuid = 0 time = 1549933942 KDB: stack backtrace db_trace_self_wrapper kdb_backtrace vpanic panic trap_fatal trap_pfault trap calltrap --- trap 0xc, eip = 0xcc277a, esp = 0x3cebd4, ebp = 0x3cec20 vmem_periodic(0,1,c671ce,a5ad79c,0,...) at vmem_periodic+0x18a/ taskqueue_run_locked taskqueue_thread_loop fork_exit fork_trampoline() at 0xffc033ba/frame 0xa3cecd4 -- trap 0, eip = 0, esp = 0xa3ced20, ebp (null)() at 0 -- Steve ___ 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"
Re: drm2 removed?
On Mon, Feb 11, 2019 at 06:42:29PM +0100, Niclas Zeising wrote: > On 2/11/19 6:36 PM, Steve Kargl wrote: > > > > The patch allows the port to be built. > > > > kldloading the i915kms module causes a 'black screen > > of death' > > > > I'll note that there seems to be a race condition in > > booting a kernel (with or without the drm2 stuff). > > During boot the kernel hangs (see below) : > > > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > Firmware Warning (ACPI): Incorrect checksum in table [TCPA] - 0x80, should > > be 0x24 (20190108/tbprint-337) > > ioapic0: Changing APIC ID to 2 > > ioapic0 irqs 0-23 on motherboard > > Launching APs: 1 > > > > *** kernel hangs here sometimes *** > > > > Timecounter "TSC" frequency 1995048460 Hz quality 1000 > > random: entropy device external interface > > kbd1 at kbdmux0 > > I assume you load the kernel module either manually with kldload or > using kld_list in rc.conf, not by loading it from the loader? After a succesful boot. I login as root and manually kldload the i915kms module. > So there is two bugs? One bug is that the kernel hangs while booting, > and the other is that you get a black screen when loading the drm module > after the kernel is mostly done booting? Yes, two bugs. kernel sometimes hangs after lauching the cpus but before random device is ready. Loading the new drm2 module cause a black screen of death. Don't know if it helps. Extracted info from /var/log/messages login[987]: ROOT LOGIN (root) ON ttyv0 (manually kldload i915kms.ko module) kernel: info: [drm] Initialized drm 1.1.0 20060810 kernel: drmn0: on vgapci0 kernel: intel_iicbb0 on drmn0 kernel: iicbus0: on iicbb0 addr 0x30 kernel: iic0: on iicbus0 kernel: iicbus1: on intel_gmbus0 kernel: iic1: on iicbus1 kernel: intel_iicbb1 on drmn0 kernel: iicbus2: on iicbb1 addr 0x30 kernel: iic2: on iicbus2 kernel: iicbus3: on intel_gmbus1 kernel: iic3: on iicbus3 kernel: intel_iicbb2 on drmn0 kernel: iicbus4: on iicbb2 addr 0x30 kernel: iic4: on iicbus4 kernel: iicbus5: on intel_gmbus2 kernel: iic5: on iicbus5 kernel: intel_iicbb3 on drmn0 kernel: iicbus6: on iicbb3 addr 0x30 kernel: iic6: on iicbus6 kernel: iicbus7: on intel_gmbus3 kernel: iic7: on iicbus7 kernel: intel_iicbb4 on drmn0 kernel: iicbus8: on iicbb4 addr 0x30 kernel: iic8: on iicbus8 kernel: iicbus9: on intel_gmbus4 kernel: iic9: on iicbus9 kernel: intel_iicbb5 on drmn0 kernel: iicbus10: on iicbb5 addr 0x30 kernel: iic10: on iicbus10 kernel: iicbus11: on intel_gmbus5 kernel: iic11: on iicbus11 kernel: vgapci0: attempting to allocate 1 MSI vectors (1 supported) kernel: msi: routing MSI IRQ 34 to local APIC 1 vector 55 kernel: vgapci0: using IRQ 34 for MSI kernel: info: [drm] MSI enabled 1 message(s) kernel: info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). kernel: info: [drm] Driver supports precise vblank timestamp query. kernel: composite sync not supported kernel: intel_sdvo_ddc_proxy397632 on drmn0 kernel: intel_sdvo_ddc_proxy397632: detached kernel: intel_sdvo_ddc_proxy397664 on drmn0 kernel: intel_sdvo_ddc_proxy397664: detached kernel: drmn0: taking over the fictitious range 0xe000-0xf000 kernel: info: [drm] initialized overlay support kernel: info: [drm] Connector LVDS-1: get mode from tunables: kernel: info: [drm] - kern.vt.fb.modes.LVDS-1 kernel: info: [drm] - kern.vt.fb.default_mode kernel: info: [drm] Connector VGA-1: get mode from tunables: kernel: info: [drm] - kern.vt.fb.modes.VGA-1 kernel: info: [drm] - kern.vt.fb.default_mode kernel: info: [drm] Connector SVIDEO-1: get mode from tunables: kernel: info: [drm] - kern.vt.fb.modes.SVIDEO-1 kernel: info: [drm] - kern.vt.fb.default_mode kernel: composite sync not supported kernel: fbd0 on drmn0 kernel: VT: Replacing driver "vga" with new "fb". -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ 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"
Re: drm2 removed?
On Mon, Feb 11, 2019 at 06:05:03PM +0100, Niclas Zeising wrote: > On 2/11/19 5:20 PM, Steve Kargl wrote: > > On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote: > >> Anyone have any idea which recent change broke the > >> drm-legacy-kmod port. This is why I raised an issue > >> with removal of drm2 from src/sys. How is suppose > >> to be fixed? > >> > > > > It was r343567. The merging of PAE and NO PAE pmap.h > > by kib removed all of the missing macros. :( > > > > Can you give attached patch a spin? > Thanks! > Regards > -- > Niclas The patch allows the port to be built. kldloading the i915kms module causes a 'black screen of death' I'll note that there seems to be a race condition in booting a kernel (with or without the drm2 stuff). During boot the kernel hangs (see below) : ---<>--- Copyright (c) 1992-2019 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT r343477 MOBILE i386 FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1) VT(vga): resolution 640x480 CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class CPU) Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x2010 AMD Features2=0x1 VT-x: (disabled in BIOS) HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3659202560 (3489 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) Firmware Warning (ACPI): Incorrect checksum in table [TCPA] - 0x80, should be 0x24 (20190108/tbprint-337) ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard Launching APs: 1 *** kernel hangs here sometimes *** Timecounter "TSC" frequency 1995048460 Hz quality 1000 random: entropy device external interface kbd1 at kbdmux0 -- Steve ___ 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"
Re: drm2 removed?
On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote: > Anyone have any idea which recent change broke the > drm-legacy-kmod port. This is why I raised an issue > with removal of drm2 from src/sys. How is suppose > to be fixed? > It was r343567. The merging of PAE and NO PAE pmap.h by kib removed all of the missing macros. :( -- Steve ___ 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"
drm2 removed?
Anyone have any idea which recent change broke the
drm-legacy-kmod port. This is why I raised an issue
with removal of drm2 from src/sys. How is suppose
to be fixed?
--- ttm_bo_manager.o ---
cc -O2 -pipe -march=core2 -fno-strict-aliasing -march=core2 -Werror -D_KERNEL
-DKLD_MODULE -nostdinc
-I/usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/drm2/../src/ -I.
-I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common -MD
-MF.depend.ttm_bo_manager.o -MTttm_bo_manager.o -mno-mmx -mno-sse -msoft-float
-ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function
-Wno-error-pointer-sign -Wno-error-shift-negative-value
-Wno-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 -c
/usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo_manager.c
-o ttm_bo_manager.o
--- ttm_bo.o ---
/usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1501:12:
error: use of undeclared identifier 'NPGPTD'
1, 0, VM_MAX_ADDRESS, PAGE_SIZE, 0, VM_MEMATTR_UNCACHEABLE);
^
./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS'
#define VM_MAX_ADDRESS VADDR(PTDPTDI, 0)
^
./machine/pmap.h:122:19: note: expanded from macro 'PTDPTDI'
#define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD)
^
./machine/param.h:98:19: note: expanded from macro 'NPDEPTD'
#define NPDEPTD (NBPTD / sizeof(pd_entry_t))
^
./machine/param.h:96:17: note: expanded from macro 'NBPTD'
#define NBPTD (NPGPTD << PAGE_SHIFT)
^
/usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1501:12:
error: use of undeclared identifier 'pd_entry_t'
./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS'
#define VM_MAX_ADDRESS VADDR(PTDPTDI, 0)
^
./machine/pmap.h:122:19: note: expanded from macro 'PTDPTDI'
#define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD)
^
./machine/param.h:98:34: note: expanded from macro 'NPDEPTD'
#define NPDEPTD (NBPTD / sizeof(pd_entry_t))
^
/usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1501:12:
error: use of undeclared identifier 'NTRPPTD'
./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS'
#define VM_MAX_ADDRESS VADDR(PTDPTDI, 0)
^
./machine/pmap.h:122:29: note: expanded from macro 'PTDPTDI'
#define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD)
^
/usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1501:12:
error: use of undeclared identifier 'NPGPTD'
./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS'
#define VM_MAX_ADDRESS VADDR(PTDPTDI, 0)
^
./machine/pmap.h:122:39: note: expanded from macro 'PTDPTDI'
#define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD)
^
/usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1505:10:
error: use of undeclared identifier 'NPGPTD'
0, VM_MAX_ADDRESS, PAGE_SIZE, 0)) {
^
./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS'
#define VM_MAX_ADDRESS VADDR(PTDPTDI, 0)
^
./machine/pmap.h:122:19: note: expanded from macro 'PTDPTDI'
#define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD)
^
./machine/param.h:98:19: note: expanded from macro 'NPDEPTD'
#define NPDEPTD (NBPTD / sizeof(pd_entry_t))
^
./machine/param.h:96:17: note: expanded from macro 'NBPTD'
#define NBPTD (NPGPTD << PAGE_SHIFT)
^
/usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm/ttm_bo.c:1505:10:
error: use of undeclared identifier 'pd_entry_t'
./machine/vmparam.h:173:31: note: expanded from macro 'VM_MAX_ADDRESS'
#define VM_MAX_ADDRESS VADDR(PTDPTDI, 0)
^
./machine/pmap.h:122:19: note: expanded from macro 'PTDPTDI'
#define PTDPTDI (NPDEPTD - NTRPPTD - NPGPTD)
^
./machine/param.h:98:34: note: expanded from macro 'NPDEPTD'
#define NPDEPTD (NBPTD / sizeof(pd_entry_t))
^
Re: Building qt5-gui port?
On Mon, Feb 11, 2019 at 10:08:08AM +0100, Tijl Coosemans wrote:
> On Sun, 10 Feb 2019 15:18:20 -0800 Steve Kargl
> wrote:
> > On Sun, Feb 10, 2019 at 03:14:15PM -0800, Mark Millard wrote:
> >>
> >> /usr/ports/Mk/Uses/qt-dist.mk has:
> >>
> >> .if ${ARCH} == i386 && empty(MACHINE_CPU:Msse2)
> >> CONFIGURE_ARGS+=-no-sse2
> >> .endif
> >
> > Hmmm. Oh well. I set CPUTYPE=core2 in /etc/make.conf.
> > During configure of qt5-gui, it does try to use sse2,
> > sse3, ssse3, and even the unsupported avx. The build
> > still dies.
>
> You probably need to build all of Qt with the same flags, starting
> with qt5-qmake and then the other dependencies of qt5-gui.
Yes, that is what I decided to do. Unfortnately, I decided
to use CPUTYPE=core2 to update kernel and world. It seems a
recent change in FreeBSD-current has broken the drm-legacy-kmod
port, so no Xorg on the laptop, so no need for qt5 ports. :-)
--
Steve
___
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"
Re: Building qt5-gui port?
On Sun, Feb 10, 2019 at 03:14:15PM -0800, Mark Millard wrote:
>
> /usr/ports/Mk/Uses/qt-dist.mk has:
>
> .if ${ARCH} == i386 && empty(MACHINE_CPU:Msse2)
> CONFIGURE_ARGS+=-no-sse2
> .endif
>
Hmmm. Oh well. I set CPUTYPE=core2 in /etc/make.conf.
During configure of qt5-gui, it does try to use sse2,
sse3, ssse3, and even the unsupported avx. The build
still dies.
--
Steve
___
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"
Re: Building qt5-gui port?
On Sun, Feb 10, 2019 at 10:32:50AM -0800, Steve Kargl wrote: > On Sun, Feb 10, 2019 at 10:24:43AM -0800, Mark Millard wrote: > > > > My reference to building for armv7 not having a problem in > > my builds is an example of a 32-bit-target context for > > qt5-gui. So i386 specific or some other aspect of how its > > build was attempted might be involved in your context. > > > > Do you use -march=native -mtune=native with clang in > freebsd-current on all those architectures? > > I can build qt5-gui with "-march=i486", "-march=i686" > "-march=i686 -mmmx", "-march=i686 -mmmx -msse". I'll > be adding each of -msse2, -msse3, -mssse3, -mcx16, > -mfxsr, and -msahf to CFLAGS to see which one is causing > the problem. > > If adding all of the -target-feature options turned on > by core2 work with i686, I'll then up i686 and repeat. > Well that was quick. Adding -msse2 to CFLAGS causes qt5-gui to die. -- Steve ___ 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"
Re: Building qt5-gui port?
On Sun, Feb 10, 2019 at 10:24:43AM -0800, Mark Millard wrote: > > My reference to building for armv7 not having a problem in > my builds is an example of a 32-bit-target context for > qt5-gui. So i386 specific or some other aspect of how its > build was attempted might be involved in your context. > Do you use -march=native -mtune=native with clang in freebsd-current on all those architectures? I can build qt5-gui with "-march=i486", "-march=i686" "-march=i686 -mmmx", "-march=i686 -mmmx -msse". I'll be adding each of -msse2, -msse3, -mssse3, -mcx16, -mfxsr, and -msahf to CFLAGS to see which one is causing the problem. If adding all of the -target-feature options turned on by core2 work with i686, I'll then up i686 and repeat. In the end, this looks like a "wrong code" issue with llvm/clang/clang++. -- Steve ___ 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"
Re: Building qt5-gui port?
On Sun, Feb 10, 2019 at 02:56:17PM +, Carmel NY wrote: > On Sun, 10 Feb 2019 06:40:01 -0800, Steve Kargl stated: > > >On Sun, Feb 10, 2019 at 08:31:12AM +0100, Tobias C. Berner wrote: > >> Moin moin > >> > >> Make sure all your qt5-(qt5-gui dependency)-ports that are already > >> installed are at 5.12.0. > >> > > > >They are all up to date. > > > >% cd /usr/ports > >% svn update > >% pkg delete -f qt5-\* > >% portmaster -Byd x11-toolkits/qt5-gui > > > >will die if I have "CFLAGS+=-march=native" in /etc/make.conf. > > > >It seems to be a clang/clang++ issue on freebsd-current. One of > >the errors is > > > >.obj/qimage.o: In function `QImage::fill(unsigned int)': > >qimage.cpp:(.text+0x2442): undefined reference to > >`qt_memfill32(unsigned int*, unsigned int, int)' > >qimage.cpp:(.text+0x2477): undefined reference to > >`qt_memfill16(unsigned short*, unsigned short, int)' > >qimage.cpp:(.text+0x268f): undefined reference to > >`qt_memfill32(unsigned int*, unsigned int, int)' > >qimage.cpp:(.text+0x26cf): undefined reference to > >`qt_memfill16(unsigned short*, unsigned short, int)' > > > >% find work -name \*.cpp | xargs grep qt_memfill16 > >path_to/qdrawhelper_sse2.cpp:void qt_memfill16(quint16 *dest, quint16 > >value, int count) path_to/qdrawhelper.cpp:void qt_memfill16(quint16 > >*dest, quint16 color, int count) mobile:root[210] find work -name > >qdrawhelper.o path_to/qdrawhelper.o > >mobile:root[211] nm path_to/qdrawhelper.o | grep memfill > > U _Z12qt_memfill16Ptti > > U _Z12qt_memfill32Pjji > >00017bb0 T _Z12qt_memfill64Pyyi > > > > Just for grins, what is the output of: > dmesg | grep -i "CPU" > mobile:kargl[201] dmesg | grep -i CPU CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class CPU) -- Steve ___ 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"
Re: Building qt5-gui port?
On Sun, Feb 10, 2019 at 08:31:12AM +0100, Tobias C. Berner wrote: > Moin moin > > Make sure all your qt5-(qt5-gui dependency)-ports that are already > installed are at 5.12.0. > The qt5 ports are up to date. % cd /usr/ports % svn update % pkg delete -f qt5-\* % cd x11-toolkits/qt5-gui % make (wait a long time) Build dies if CFLAGS+=-march=native is in /etc/make.conf. -- Steve ___ 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"
Re: Building qt5-gui port?
On Sun, Feb 10, 2019 at 08:31:12AM +0100, Tobias C. Berner wrote: > Moin moin > > Make sure all your qt5-(qt5-gui dependency)-ports that are already > installed are at 5.12.0. > They are all up to date. % cd /usr/ports % svn update % pkg delete -f qt5-\* % portmaster -Byd x11-toolkits/qt5-gui will die if I have "CFLAGS+=-march=native" in /etc/make.conf. It seems to be a clang/clang++ issue on freebsd-current. One of the errors is .obj/qimage.o: In function `QImage::fill(unsigned int)': qimage.cpp:(.text+0x2442): undefined reference to `qt_memfill32(unsigned int*, unsigned int, int)' qimage.cpp:(.text+0x2477): undefined reference to `qt_memfill16(unsigned short*, unsigned short, int)' qimage.cpp:(.text+0x268f): undefined reference to `qt_memfill32(unsigned int*, unsigned int, int)' qimage.cpp:(.text+0x26cf): undefined reference to `qt_memfill16(unsigned short*, unsigned short, int)' % find work -name \*.cpp | xargs grep qt_memfill16 path_to/qdrawhelper_sse2.cpp:void qt_memfill16(quint16 *dest, quint16 value, int count) path_to/qdrawhelper.cpp:void qt_memfill16(quint16 *dest, quint16 color, int count) mobile:root[210] find work -name qdrawhelper.o path_to/qdrawhelper.o mobile:root[211] nm path_to/qdrawhelper.o | grep memfill U _Z12qt_memfill16Ptti U _Z12qt_memfill32Pjji 00017bb0 T _Z12qt_memfill64Pyyi -- Steve ___ 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"
Re: Building qt5-gui port?
On Sat, Feb 09, 2019 at 07:32:27PM -0800, Steve Kargl wrote: > Anyone have any pointers on building x11-toolkits/qt5-gui on > FreeBSD-current? My attempts end with > > c++ -Wl,--as-needed (boat load of info removed). > qdrawhelper.cpp:(.text+0x2d0ba): undefined reference to > `comp_func_Plus_sse2(unsigned int*, unsigned int const*, int, unsigned int)' > c++: error: linker command failed with exit code 1 (use -v to see invocation) > *** Error code 1 > It seems that clang cannot use -march=native (at least on my Intel(R) Core(TM)2 Duo CPU T7250). -- Steve ___ 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"
Building qt5-gui port?
Anyone have any pointers on building x11-toolkits/qt5-gui on FreeBSD-current? My attempts end with c++ -Wl,--as-needed -fstack-protector -Wl,--no-undefined -Wl,--version-script,QtGui.version -pthread -Wl,-rpath,/usr/local/lib/qt5 -shared -Wl,-Bsymbolic-functions -Wl,--dynamic-list,/usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src-5.12.0/src/gui/QtGui.dynlist -Wl,-soname,libQt5Gui.so.5 -o libQt5Gui.so.5.12.0 .obj/qaccessible.o .obj/qaccessiblecache.o .obj/qaccessibleobject.o .obj/qaccessibleplugin.o .obj/qplatformaccessibility.o .obj/qaccessiblebridge.o .obj/qgenericpluginfactory.o .obj/qgenericplugin.o .obj/qwindowsysteminterface.o .obj/qplatforminputcontextfactory.o .obj/qplatforminputcontextplugin.o .obj/qplatforminputcontext.o .obj/qplatformintegration.o .obj/qplatformscreen.o .obj/qplatformintegrationfactory.o .obj/qplatformintegrationplugin.o .obj/qplatformtheme.o .obj/qplatformthemefactory.o .obj/qplatformthemeplugin.o .obj/qplatformwindow.o .obj/qplatformoffscreensurface.o .obj/qplatformcursor.o .obj/qplatformclipboard.o .obj/qplatformnativei nterface.o .obj/qsessionmanager.o .obj/qsurfaceformat.o .obj/qguiapplication.o .obj/qwindow.o .obj/qoffscreensurface.o .obj/qplatformsurface.o .obj/qsurface.o .obj/qclipboard.o .obj/qcursor.o .obj/qevent.o .obj/qinputmethod.o .obj/qinternalmimedata.o .obj/qkeysequence.o .obj/qkeymapper.o .obj/qpalette.o .obj/qguivariant.o .obj/qscreen.o .obj/qshortcutmap.o .obj/qstylehints.o .obj/qtouchdevice.o .obj/qplatformsharedgraphicscache.o .obj/qplatformdialoghelper.o .obj/qplatformservices.o .obj/qplatformsystemtrayicon.o .obj/qplatformsessionmanager.o .obj/qplatformmenu.o .obj/qpixelformat.o .obj/qpaintdevicewindow.o .obj/qrasterwindow.o .obj/qplatformgraphicsbuffer.o .obj/qplatformgraphicsbufferhelper.o .obj/qinputdevicemanager.o .obj/qhighdpiscaling.o .obj/qtestsupport_gui.o .obj/qdnd.o .obj/qdrag.o .obj/qplatformdrag.o .obj/qshapedpixmapdndwindow.o .obj/qsimpledrag.o .obj/qplatformopenglcontext.o .obj/qopenglcontext.o .obj/qopenglwindow.o .obj/q bitmap.o .obj/qimage.o .obj/qimage_conversions.o .obj/qimageiohandler.o .obj/qimagereader.o .obj/qimagereaderwriterhelpers.o .obj/qimagewriter.o .obj/qpaintengine_pic.o .obj/qpicture.o .obj/qpictureformatplugin.o .obj/qpixmap.o .obj/qpixmapcache.o .obj/qplatformpixmap.o .obj/qpixmap_raster.o .obj/qpixmap_blitter.o .obj/qimagepixmapcleanuphooks.o .obj/qicon.o .obj/qiconloader.o .obj/qiconengine.o .obj/qiconengineplugin.o .obj/qmovie.o .obj/qbmphandler.o .obj/qppmhandler.o .obj/qxbmhandler.o .obj/qxpmhandler.o .obj/qpnghandler.o .obj/qfont.o .obj/qfontengine.o .obj/qfontengineglyphcache.o .obj/qfontsubset.o .obj/qfontmetrics.o .obj/qfontdatabase.o .obj/qtextengine.o .obj/qtextlayout.o .obj/qtextformat.o .obj/qtextobject.o .obj/qtextoption.o .obj/qfragmentmap.o .obj/qtextdocument.o .obj/qtextdocument_p.o .obj/qtexthtmlparser.o .obj/qabstracttextdocumentlayout.o .obj/qtextdocumentlayout.o .obj/qtextcursor.o .obj/qtextdocumentfragment.o .obj/q textimagehandler.o .obj/qtexttable.o .obj/qtextlist.o .obj/qtextdocumentwriter.o .obj/qsyntaxhighlighter.o .obj/qstatictext.o .obj/qrawfont.o .obj/qglyphrun.o .obj/qdistancefield.o .obj/qinputcontrol.o .obj/qfontengine_qpf2.o .obj/qplatformfontdatabase.o .obj/qharfbuzzng.o .obj/qtextodfwriter.o .obj/qzip.o .obj/qcssparser.o .obj/qbackingstore.o .obj/qbezier.o .obj/qblendfunctions.o .obj/qblittable.o .obj/qbrush.o .obj/qcolor.o .obj/qcolorprofile.o .obj/qcompositionfunctions.o .obj/qcosmeticstroker.o .obj/qdrawhelper.o .obj/qemulationpaintengine.o .obj/qgrayraster.o .obj/qimagescale.o .obj/qmatrix.o .obj/qmemrotate.o .obj/qoutlinemapper.o .obj/qpagedpaintdevice.o .obj/qpagelayout.o .obj/qpagesize.o .obj/qpaintdevice.o .obj/qpaintengine.o .obj/qpaintengineex.o .obj/qpaintengine_blitter.o .obj/qpaintengine_raster.o .obj/qpainter.o .obj/qpainterpath.o .obj/qpathclipper.o .obj/qpdf.o .obj/qpdfwriter.o .obj/qpen.o .obj/qpolygon.o .obj/qraster izer.o .obj/qregion.o .obj/qstroker.o .obj/qtextureglyphcache.o .obj/qtransform.o .obj/qtriangulatingstroker.o .obj/qtriangulator.o .obj/qplatformbackingstore.o .obj/qpathsimplifier.o .obj/qcssutil.o .obj/qdesktopservices.o .obj/qvalidator.o .obj/qgridlayoutengine.o .obj/qabstractlayoutstyleinfo.o .obj/qlayoutpolicy.o .obj/qshaderformat.o .obj/qshadergenerator.o .obj/qshadergraph.o .obj/qshadergraphloader.o .obj/qshaderlanguage.o .obj/qshadernode.o .obj/qshadernodeport.o .obj/qshadernodesloader.o .obj/qtexturefiledata.o .obj/qtexturefilereader.o .obj/qpkmhandler.o .obj/qktxhandler.o .obj/qgenericmatrix.o .obj/qmatrix4x4.o .obj/qquaternion.o .obj/qvector2d.o .obj/qvector3d.o .obj/qvector4d.o .obj/qopengl.o .obj/qopenglfunctions.o .obj/qopenglframebufferobject.o .obj/qopenglpaintdevice.o
Re: devel/jsoncpp and staging?
On Wed, Dec 19, 2018 at 03:46:33AM +0900, Yasuhiro KIMURA wrote: > From: Steve Kargl > Subject: Re: devel/jsoncpp and staging? > Date: Tue, 18 Dec 2018 10:07:05 -0800 > > > Thanks for the pointer to email thread. Guess I'll > > upgrade from 341703 to top-of-tree and see if that > > fixes the issue. I reverted recent changes to sh > > and bmake, but those did not seem to help. > > I guess the problem comes from kernel rather than userland. So I > recommend you to upgrade or rollback kernel. > Thanks for the info. A complete buildworld/buildkernel cycle has "fixed" the issue. -- Steve ___ 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"
Re: devel/jsoncpp and staging?
On Tue, Dec 18, 2018 at 08:54:29AM +0100, Mathieu Arnold wrote:
> On Mon, Dec 17, 2018 at 07:25:10PM -0800, Steve Kargl wrote:
> > On Mon, Dec 17, 2018 at 05:48:57PM -0800, Steve Kargl wrote:
> > > I must be missing a change in how staging works.
> > >
> > > % cd /usr/ports/devel/jsoncpp
> > > % make
> > >
> > > ===> Staging for jsoncpp-1.8.1_5
> > > ===> Generating temporary packing list
> > > (cd /usr/ports/devel/jsoncpp/work/jsoncpp-1.8.1/include/ && /bin/sh -c
> > > '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) &&
> > > /usr/bin/find -Ed $1 $3 \( -type d -exec /bin/sh -c '\''cd '\''$2'\''
> > > && chmod 755 "$@"'\'' . {} + -o -type f -exec /bin/sh -c '\''cd
> > > '\''$2'\'' && chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE json/
> > > /usr/ports/devel/jsoncpp/work/stage/usr/local/include/jsoncpp/)
> > > chmod: json/allocator.h: No such file or directory
> > > chmod: json/assertions.h: No such file or directory
> > > chmod: json/autolink.h: No such file or directory
> > > chmod: json/config.h: No such file or directory
> > > chmod: json/features.h: No such file or directory
> > > chmod: json/forwards.h: No such file or directory
> > > chmod: json/json.h: No such file or directory
> > > chmod: json/reader.h: No such file or directory
> > > chmod: json/value.h: No such file or directory
> > > chmod: json/version.h: No such file or directory
> > > chmod: json/writer.h: No such file or directory
> > >
> > > % ls work/stage/usr/local/include/jsoncpp/json
> > >
> > >
> > > Now, let's re-run make
> > >
> > > % make
> >
> > Same problem with news/xpn, except running make multiple
> > times does not correct the missing files problem. So,
> > is there away to use the ports collection with staging
> > disabled? src.conf documents WITHOUT_STAGING, but the
> > port collections seems to ignore this varible.
>
> src.conf is about the source tree, it has absolutely nothing to do with
> ports. Staging is a mandatory feature of every port.
That's unfortnutely.
> I cannot reproduce the error you encounter, what version of FreeBSD are
> you running?
FreeBSD sleepdirt 13.0-CURRENT FreeBSD 13.0-CURRENT r341703 HPC amd64
This corresponds to a /usr/src from Dec. 7, 2018.
I did not have this problem circa Oct. 5th. That's when I
successfully installed news/xpn. sh(1) has had 4 commits and
bmake was updated on Dec. 5. Perhaps, an incompatible change
has entered the tree. The end of 'make -dA' gives
do-install:> =
/bin/mkdir -p /usr/ports/devel/jsoncpp/work/stage/usr/local/include/jsoncpp
Execute: '/bin/mkdir -p
/usr/ports/devel/jsoncpp/work/stage/usr/local/include/jsoncpp'
Applying[.MAKE.EXPORTED] :O to "META_MODE LANG LC_ALL LANG LC_ALL"
Result[.MAKE.EXPORTED] of :O is "LANG LANG LC_ALL LC_ALL META_MODE"
Applying[.MAKE.EXPORTED] :u to "LANG LANG LC_ALL LC_ALL META_MODE"
Result[.MAKE.EXPORTED] of :u is "LANG LC_ALL META_MODE"
Applying[GH_TAGNAME] :S to "1.8.1"
Modifier pattern: "/"
Modifier pattern: "-"
Result[GH_TAGNAME] of :S is "1.8.1"
Applying[GH_TAGNAME_SANITIZED] :C to "1.8.1"
Modifier pattern: "^[vV]([0-9])"
Modifier pattern: "\1"
Result[GH_TAGNAME_SANITIZED] of :C is "1.8.1"
Applying[GH_TAGNAME_SANITIZED] :S to "1.8.1"
Modifier pattern: "+"
Modifier pattern: "-"
Result[GH_TAGNAME_SANITIZED] of :S is "1.8.1"
(cd /usr/ports/devel/jsoncpp/work/jsoncpp-1.8.1/include/ && /bin/sh -c
'(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) &&
/usr/bin/find -Ed $1 $3 \( -type d -exec /bin/sh -c '\''cd '\''$2'\'' &&
chmod 755 "$@"'\'' . {} + -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' &&
chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE json/
/usr/ports/devel/jsoncpp/work/stage/usr/local/include/jsoncpp/)
Execute: '(cd /usr/ports/devel/jsoncpp/work/jsoncpp-1.8.1/include/ && /bin/sh
-c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) &&
/usr/bin/find -Ed $1 $3 \( -type d -exec /bin/sh -c '\''cd '\''$2'\'' &&
chmod 755 "$@"'\'' . {} + -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' &&
chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE json/
/usr/ports/devel/jsoncpp/work/stage/usr/local/include/jsoncpp/)'
Applying[.MAKE.EXPORTED] :O to "META_MODE LANG LC_ALL LANG LC_ALL"
Result[.MAKE.EXPORTED] of :O is "LANG LANG LC_ALL LC_ALL
Re: devel/jsoncpp and staging?
On Mon, Dec 17, 2018 at 05:48:57PM -0800, Steve Kargl wrote:
> I must be missing a change in how staging works.
>
> % cd /usr/ports/devel/jsoncpp
> % make
>
> ===> Staging for jsoncpp-1.8.1_5
> ===> Generating temporary packing list
> (cd /usr/ports/devel/jsoncpp/work/jsoncpp-1.8.1/include/ && /bin/sh -c
> '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) &&
> /usr/bin/find -Ed $1 $3 \( -type d -exec /bin/sh -c '\''cd '\''$2'\'' &&
> chmod 755 "$@"'\'' . {} + -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' &&
> chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE json/
> /usr/ports/devel/jsoncpp/work/stage/usr/local/include/jsoncpp/)
> chmod: json/allocator.h: No such file or directory
> chmod: json/assertions.h: No such file or directory
> chmod: json/autolink.h: No such file or directory
> chmod: json/config.h: No such file or directory
> chmod: json/features.h: No such file or directory
> chmod: json/forwards.h: No such file or directory
> chmod: json/json.h: No such file or directory
> chmod: json/reader.h: No such file or directory
> chmod: json/value.h: No such file or directory
> chmod: json/version.h: No such file or directory
> chmod: json/writer.h: No such file or directory
>
> % ls work/stage/usr/local/include/jsoncpp/json
>
>
> Now, let's re-run make
>
> % make
Same problem with news/xpn, except running make multiple
times does not correct the missing files problem. So,
is there away to use the ports collection with staging
disabled? src.conf documents WITHOUT_STAGING, but the
port collections seems to ignore this varible.
--
Steve
___
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"
devel/jsoncpp and staging?
I must be missing a change in how staging works.
% cd /usr/ports/devel/jsoncpp
% make
===> Staging for jsoncpp-1.8.1_5
===> Generating temporary packing list
(cd /usr/ports/devel/jsoncpp/work/jsoncpp-1.8.1/include/ && /bin/sh -c
'(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) &&
/usr/bin/find -Ed $1 $3 \( -type d -exec /bin/sh -c '\''cd '\''$2'\'' &&
chmod 755 "$@"'\'' . {} + -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' &&
chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE json/
/usr/ports/devel/jsoncpp/work/stage/usr/local/include/jsoncpp/)
chmod: json/allocator.h: No such file or directory
chmod: json/assertions.h: No such file or directory
chmod: json/autolink.h: No such file or directory
chmod: json/config.h: No such file or directory
chmod: json/features.h: No such file or directory
chmod: json/forwards.h: No such file or directory
chmod: json/json.h: No such file or directory
chmod: json/reader.h: No such file or directory
chmod: json/value.h: No such file or directory
chmod: json/version.h: No such file or directory
chmod: json/writer.h: No such file or directory
% ls work/stage/usr/local/include/jsoncpp/json
Now, let's re-run make
% make
===> Staging for jsoncpp-1.8.1_5
===> Generating temporary packing list
(cd /usr/ports/devel/jsoncpp/work/jsoncpp-1.8.1/include/ && /bin/sh -c
'(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) &&
/usr/bin/find -Ed $1 $3 \( -type d -exec /bin/sh -c '\''cd '\''$2'\'' &&
chmod 755 "$@"'\'' . {} + -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' &&
chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE json/
/usr/ports/devel/jsoncpp/work/stage/usr/local/include/jsoncpp/)
install -m 0644
/usr/ports/devel/jsoncpp/work/jsoncpp-1.8.1/libs/linux-gcc-FreeBSD/libjsoncpp.a
/usr/ports/devel/jsoncpp/work/stage/usr/local/lib
install -s -m 0644
/usr/ports/devel/jsoncpp/work/jsoncpp-1.8.1/libs/linux-gcc-FreeBSD/libjsoncpp.so.1.8.1
/usr/ports/devel/jsoncpp/work/stage/usr/local/lib
/bin/ln -s libjsoncpp.so.1.8.1
/usr/ports/devel/jsoncpp/work/stage/usr/local/lib/libjsoncpp.so.1
/bin/ln -s libjsoncpp.so.1.8.1
/usr/ports/devel/jsoncpp/work/stage/usr/local/lib/libjsoncpp.so
cp -f /usr/ports/devel/jsoncpp/work/jsoncpp-1.8.1/pkg-config/jsoncpp.pc.in
/usr/ports/devel/jsoncpp/work/stage/usr/local/libdata/pkgconfig/jsoncpp.pc
> Compressing man pages (compress-man)
% ls work/stage/usr/local/include/jsoncpp/json
allocator.h config.hjson.h version.h
assertions.hfeatures.h reader.hwriter.h
autolink.h forwards.h value.h
The missing files are suddenly found. Seems to be a race in
staging feature.
--
Steve
___
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"
Re: Massive PORTREVSION bump for gcc8
On Wed, Dec 12, 2018 at 10:29:59AM -0800, Kevin Oberman wrote: > This morning the PORTREVISION on at least hundreds of ports was bumped > because gcc8 was declared as the "canonical" version. As a result, I will > have about 300 ports to rebuild which will take many hours. > Why? > > If a port is built and running properly with gcc7, I see no reason to force > the rebuild of all of the ports that are built with gcc7. This will lead to > a delay of probably several days in getting updated packages built for > LATEST repos and will consume hours of CPU time for everyone using > poudriere or building from ports. This even impacts (slightly) climate > change with the extra energy used in rebuilding all of those ports across > the globe. > > Perhaps there was a real reason this was required. I have certainly never > seen it before for any new compiler version to either gcc or llvm. Does adding DEFAULT_VERSIONS+=GCC=7 to /etc/make.conf prevent the need to update 300 ports. -- Steve ___ 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"
Re: Strange interaction between py-pyglet and py-numpy
On Mon, Nov 26, 2018 at 07:33:12PM -0500, Diane Bruce wrote: > On Mon, Nov 26, 2018 at 11:59:36PM +, Montgomery-Smith, Stephen wrote: > > > > Original error was: /lib/libgcc_s.so.1: version GCC_4.8.0 required by > > /usr/local/lib/gcc7/libgfortran.so.4 not found > > > > > > Any ideas? > > > I want my pony still. > > https://wiki.freebsd.org/libgcc%20problem > setenv LD_LIBRARY_PATH path/to/correct/libgcc_s.so.1 -- Steve ___ 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"
Re: Inkscape package troubles, "libicuuc.so.62" not found
On Tue, Nov 20, 2018 at 08:52:58AM -0800, bob prohaska wrote: > On Mon, Nov 19, 2018 at 04:43:18PM -0800, Steve Kargl wrote: > > On Mon, Nov 19, 2018 at 03:57:22PM -0800, bob prohaska wrote: > > > Using pkg delete resolved the ImageMagick vs ImageMagic6 conflict, > > > allowing > > > inkscape to build successfully from ports on an RPI3. > > > > > > Alas, I somehow deleted libicuuc.so.62, causing a runtime failure. > > > Rebuilding > > > devel/icu got version 63, so that didn't help. > > > > > > > The simple (temporary) workaround is > > > > echo 'libicuuc.so.62 libicuuc.so.63' >> /etc/libmap.conf > > > > Thank you very much, I didn't know about libmap.conf. > You're welcomed. Note, this should be considered temporary as the library version bump should indicate a change in some function interface. I've never run into an issue, but one may exists. You should probably do 'pkg check -B'. This will identify which ports depend on the missing library, and you can update those. Once 'pkg check -B' returns 100%, you can remove the contents from libmap.conf -- Steve ___ 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"
Re: Inkscape package troubles, "libicuuc.so.62" not found
On Mon, Nov 19, 2018 at 03:57:22PM -0800, bob prohaska wrote: > Using pkg delete resolved the ImageMagick vs ImageMagic6 conflict, allowing > inkscape to build successfully from ports on an RPI3. > > Alas, I somehow deleted libicuuc.so.62, causing a runtime failure. Rebuilding > devel/icu got version 63, so that didn't help. > > Noticing that inkscape is now available as a package, I tried installing > that, expecting it to recover the older library needed for the current > version of inkscape. The install brought down roughly 1 GB of files, > but not the needed library. > > Is there a resolution to this dilemma, other than just waiting for > inkscape to catch up? Is it possible to determine which revision of > the ports tree can make a runnable version of a particular port? The simple (temporary) workaround is echo 'libicuuc.so.62 libicuuc.so.63' >> /etc/libmap.conf -- Steve ___ 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"
Re: pkg version is slowwww
On Fri, Oct 26, 2018 at 08:40:07PM +0200, Michael Gmelin wrote: > > > On 26. Oct 2018, at 20:03, Steve Kargl > > wrote: > > > > I recently updated to pkg-1.10.5_5, and I now > > find to command "pkg version -vl '<'" to be > > much slower than previous versions. > > > > Four consecutive executions of "time pkg version -vl '<'" > > yields > > > > 54.15 real27.28 user25.66 sys > > 48.80 real26.04 user23.01 sys > > 48.35 real26.30 user22.59 sys > > 48.43 real26.54 user22.32 sys > > > > During one of these timings, top(1) shows > > > > 47519 root1 -8021M12M piperd 0 0:00 0.20% pkg > > > > Is slow down expected? > > > > Note, "time pkg info" gives > > > >0.01 real 0.00 user 0.00 sys > > > > What is the timing when using “-R” and when using “-I”? > Hmmm, it seems that -I may have found the cause of my observed slowdown. % time pkg version -I -vl '<' pkg: Can't access /usr/ports/INDEX-13: No such file or directory 0.00 real 0.00 user 0.00 sys I cannot find an announcement that FreeBSD-12 had branched. I have /usr/ports/INDEX-12, but I also rebuilt world yesterday where I track head and obviously head sources are from after the branch. % uname -v FreeBSD 13.0-CURRENT r339736 HPC Deleting /usr/ports/INDEX-12 and doing "make fetchindex" in /usr/ports pulls the INDEX-13 file. I now see % time pkg version -vl '<' 0.09 real 0.09 user 0.00 sys which is what I expected. Apologies for the noise. -- Steve ___ 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"
pkg version is slowwww
I recently updated to pkg-1.10.5_5, and I now find to command "pkg version -vl '<'" to be much slower than previous versions. Four consecutive executions of "time pkg version -vl '<'" yields 54.15 real27.28 user25.66 sys 48.80 real26.04 user23.01 sys 48.35 real26.30 user22.59 sys 48.43 real26.54 user22.32 sys During one of these timings, top(1) shows 47519 root1 -8021M12M piperd 0 0:00 0.20% pkg Is slow down expected? Note, "time pkg info" gives 0.01 real 0.00 user 0.00 sys -- Steve ___ 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"
Re: Building math/octave with QT4?
On Wed, Jun 13, 2018 at 12:32:28AM +, Montgomery-Smith, Stephen wrote: > On 06/12/2018 04:20 PM, Steve Kargl wrote: > > On Tue, Jun 12, 2018 at 08:28:07PM +, Montgomery-Smith, Stephen wrote: > >> > >> Or if you just send him a request without a patch, he may get > >> around to it sometime. > > > > This seems to work. > > > > cd /usr/ports > > svn merge -r 469260:469259 . > > > > What exactly are you doing when this error occurs? (The one you didn't > include in the snippet above?) I never experienced it myself. It shows up almost immediately if I load octave-forge-signal. portmaster math/octave portmaster math/octave-forge-signal My .octaverc file contains pkg load netcdf pkg load signal loading signal also loads octave-forge-control. At csh prompt % octave --gui & within a few minutes of the GUI opening either try resizing the window or a pane in the window or dragging the window. Watch octave drop core. -- Steve ___ 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"
Re: Building math/octave with QT4?
On Tue, Jun 12, 2018 at 08:28:07PM +, Montgomery-Smith, Stephen wrote: > > Or if you just send him a request without a patch, he may get > around to it sometime. This seems to work. cd /usr/ports svn merge -r 469260:469259 . -- Steve ___ 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"
Building math/octave with QT4?
Is it possible to build math/octave with QT4? The recent switch to require QT5 in r469260 leads to an unusable octave (unless one's intention is to debug QT5). % gdb81 /usr/local/libexec/octave/4.4.0/exec/amd64-portbld-freebsd12.0/octave-gui octave-gui.core > bt #0 0x0002056b244d in QVariant::QVariant(QVariant const&) () from /usr/local/lib/qt5/libQt5Core.so.5 [Current thread is 1 (LWP 101275)] (gdb) bt #0 0x0002056b244d in QVariant::QVariant(QVariant const&) () from /usr/local/lib/qt5/libQt5Core.so.5 #1 0x000227c233c9 in ?? () from /usr/local/lib/qt5/plugins/sqldrivers/libqsqlite.so #2 0x000227c1eba2 in ?? () from /usr/local/lib/qt5/plugins/sqldrivers/libqsqlite.so #3 0x000205117351 in QSqlResult::execBatch(bool) () from /usr/local/lib/qt5/libQt5Sql.so.5 #4 0x000203cf9ca2 in ?? () from /usr/local/lib/qt5/libQt5Help.so.5 #5 0x000203cfbd42 in ?? () from /usr/local/lib/qt5/libQt5Help.so.5 #6 0x0002054b24ea in ?? () from /usr/local/lib/qt5/libQt5Core.so.5 #7 0x000200d7e426 in thread_start (curthread=0x232679100) at /usr/src/lib/libthr/thread/thr_create.c:291 #8 0x in ?? () Backtrace stopped: Cannot access memory at address 0x7fffbebf4000 -- Steve ___ 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"
Re: Runtime loader issue
On Wed, May 09, 2018 at 04:45:51PM -0700, Steve Kargl wrote: > In review PR 228007, it came to my attention some individuals are > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD > issue". See It seems we've had the same discussion 2 years ago. My time flies. ttps://lists.freebsd.org/pipermail/freebsd-ports/2016-August/104384.html -- Steve ___ 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"
Re: Runtime loader issue
On Thu, May 10, 2018 at 06:21:51PM +0200, Tijl Coosemans wrote: > On Wed, 9 May 2018 16:45:51 -0700 Steve Kargl > <s...@troutmask.apl.washington.edu> wrote: > > > > So, the runtime loader finds 6 instead of 716, tries to link, > > fails, and issues an error message. There are a number ways to > > fix this issue. > > > > 1) By far, the best solution would be to stop hijacking the libgcc > >name in libraries installed on FreeBSD that are not related to > >actual GCC software. > > > > % ls -l /lib/libgcc* /usr/lib/libgcc* > > (trimming lines) > > /lib/libgcc_s.so.1 > > /usr/lib/libgcc.a@ -> libcompiler_rt.a > > /usr/lib/libgcc_eh.a > > /usr/lib/libgcc_eh_p.a > > /usr/lib/libgcc_p.a@ -> libcompiler_rt_p.a > > /usr/lib/libgcc_s.so@ -> ../../lib/libgcc_s.so.1 > > > >Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)? Yes, I'm > >aware that clang does not work on all archs and the ancient gcc > >lives on. > > > > 2) Given the expected push back againt solution 1), this solution > >proposes bumping the library version for /lib/libgcc_s.so.1 from > >1 to some larger value, say, 10. It is unlikely that GCC will > >bump its shared library number anytime soon. GCC bumped it from > >0 to 1 some 16 years ago. > > > >https://gcc.gnu.org/viewcvs/gcc?view=revision=43316 > > > >This solution, however, papers over the general problem with > >name clashes. > > > > libgcc_s.so implements the _Unwind_* API to handle stack unwinding. This > code is shared between all compilers and languages because the stack can > contain frames from different compilers and languages. So, you cannot > change the name or version of the library. Well, yes one could change the name and/or shared library number. All those other tools would then need to be adapted to look for a renamed or number-bumped library. Yes, painful. > I've been testing the attached patch in combination with the ports tree > patch from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228046. > > The patch makes three changes to /etc/rc.d/ldconfig: > 1) Use 'sort -r' so /usr/local/lib/gcc7 appears before /usr/local/lib/gcc6. > 2) Move hardcoded paths like /lib and /usr/lib to /etc/defaults/rc.conf >so the order relative to other paths can be configured. > 3) Change the order of ldconfig_local_dirs and ldconfig_paths so /lib and >/usr/lib appear last. This brings rc.d/ldconfig in line with compilers >and rtld(1) which also search /lib and /usr/lib last. This appears to work around the problem with libgcc_s.so.1. It would be a welcomed solution to so-called "gfortran's FreeBSD issue", but is does not solve the problem with name clashes. It is possible to have two independent libraries for independent projects where no shuffling of order in hints will work. -- Steve ___ 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"
Re: Runtime loader issue
On Thu, May 10, 2018 at 10:24:52AM -0400, Diane Bruce wrote: > On Thu, May 10, 2018 at 10:46:31AM +0300, Gleb Popov wrote: > > On Thu, May 10, 2018 at 2:45 AM, Steve Kargl < > > s...@troutmask.apl.washington.edu> wrote: > > > > > In review PR 228007, it came to my attention some individuals are > > > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD > > > issue". See > > Indeed. I've tried to make it clear it is a name conflict with libgcc > in my own bug reports on the subject. > > > > > > > https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html > > > > > > The problem can be summarized by the following > ... > > > gfortran7 is installed from ports/lang/gcc7. This is not > > > a "gfortran's FreeBSD issue". This is a FreeBSD loader issue. > > > > > > Specifically, there is a shared library name clash. > > > > > > % ldconfig -r | grep gcc_ > > > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > > >716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 > > Yep. > See https://wiki.freebsd.org/libgcc%20problem > Interesting page. I was aware that in the past you tried working out a solution to the problem. I did not realize you docoumented the issue. A few corrections to your wiki page. 1) The correct spelling of the name of the language is Fortran (with a capital F). It has been the official standard spelling since Fortran 90. 2) You have "... to always support quad math (*8) and ...". Quad precision in gfortran is REAL(16) (the REAL*16 notation is nonstandard). 3) "subsitute" is normally spelled with an extra 't'. :-) > > > So, the runtime loader finds 6 instead of 716, tries to link, > > > fails, and issues an error message. There are a number ways to > > > fix this issue. > > > > > > 1) By far, the best solution would be to stop hijacking the libgcc > > >name in libraries installed on FreeBSD that are not related to > > >actual GCC software. > > Agreed, however this has the side effect of meaning conflicts with libraries > between clang and gcc libs. Notably gfortran and flang use different > conventions for I/O :( > > See http://people.FreeeBSD.org/~db/fortran_libs.txt > Page doesn't appear to exist? If I go to https://people.freebsd.org/homepage.html you're not listed. > > >Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)? Yes, I'm > > >aware that clang does not work on all archs and the ancient gcc > > >lives on. > > > > > I've argued for this as well and frankly I still think it is the best > solution all around. > > > > 2) Given the expected push back againt solution 1), this solution > > >proposes bumping the library version for /lib/libgcc_s.so.1 from > > >1 to some larger value, say, 10. It is unlikely that GCC will > > >bump its shared library number anytime soon. GCC bumped it from > > >0 to 1 some 16 years ago. > > > > > >https://gcc.gnu.org/viewcvs/gcc?view=revision=43316 > > > > > >This solution, however, papers over the general problem with > > >name clashes. > > Yep. I know work is slowly being done to modernise our libgcc already > but the toolchain folks are busy... > > > > > > > 3) This solution is to actually fix the runtime loader. If an error > > >occurs with loading a shared library, then iterate over the entries > > >in the hints file to check to see if another hint would satisfy > > >the linking. Here, instead of issuing the above error, the loader > > >would find entry 716, and load the correct libgcc_s.so.1. > > This breaks if the bad libgcc is already linked. We'd have to rip > out the original bindings at run time, then re-bind to a new libgcc. > I looked at the rtld code months ago. Nasty and silly. > > > > > > >Admittedly, I haven't looked to see how difficult this solution > > >would be. > > Very ;) Just started reading the source code. Don't scare the unwary. :-) -- Steve ___ 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"
Runtime loader issue
In review PR 228007, it came to my attention some individuals are mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD issue". See https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html The problem can be summarized by the following % gfortran7 -o z h.f90 % ./z /lib/libgcc_s.so.1: version GCC_4.8.0 required by \ /usr/local/lib/gcc7/libgfortran.so.4 not found gfortran7 is installed from ports/lang/gcc7. This is not a "gfortran's FreeBSD issue". This is a FreeBSD loader issue. Specifically, there is a shared library name clash. % ldconfig -r | grep gcc_ 6:-lgcc_s.1 => /lib/libgcc_s.so.1 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 % ldd z z: libgfortran.so.4 => /usr/local/lib/gcc7/libgfortran.so.4 (0x200645000) libm.so.5 => /lib/libm.so.5 (0x200a17000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x200a4b000) libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200a63000) libc.so.7 => /lib/libc.so.7 (0x200ca3000) So, the runtime loader finds 6 instead of 716, tries to link, fails, and issues an error message. There are a number ways to fix this issue. 1) By far, the best solution would be to stop hijacking the libgcc name in libraries installed on FreeBSD that are not related to actual GCC software. % ls -l /lib/libgcc* /usr/lib/libgcc* (trimming lines) /lib/libgcc_s.so.1 /usr/lib/libgcc.a@ -> libcompiler_rt.a /usr/lib/libgcc_eh.a /usr/lib/libgcc_eh_p.a /usr/lib/libgcc_p.a@ -> libcompiler_rt_p.a /usr/lib/libgcc_s.so@ -> ../../lib/libgcc_s.so.1 Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)? Yes, I'm aware that clang does not work on all archs and the ancient gcc lives on. 2) Given the expected push back againt solution 1), this solution proposes bumping the library version for /lib/libgcc_s.so.1 from 1 to some larger value, say, 10. It is unlikely that GCC will bump its shared library number anytime soon. GCC bumped it from 0 to 1 some 16 years ago. https://gcc.gnu.org/viewcvs/gcc?view=revision=43316 This solution, however, papers over the general problem with name clashes. 3) This solution is to actually fix the runtime loader. If an error occurs with loading a shared library, then iterate over the entries in the hints file to check to see if another hint would satisfy the linking. Here, instead of issuing the above error, the loader would find entry 716, and load the correct libgcc_s.so.1. Admittedly, I haven't looked to see how difficult this solution would be. 4) Bump the shared library number of the individual ports. As a proof of concept, I've done this with ports/lang/gcc6. % cat /usr/ports/lang/gcc6/files/patch-t-slibgcc --- libgcc/config/t-slibgcc.orig2018-05-08 12:47:42.334495000 -0700 +++ libgcc/config/t-slibgcc 2018-05-08 12:45:26.872312000 -0700 @@ -20,7 +20,7 @@ SHLIB_EXT = .so SHLIB_SOLINK = @shlib_base_name@.so -SHLIB_SOVERSION = 1 +SHLIB_SOVERSION = 2 SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION) SHLIB_MAP = @shlib_map_file@ SHLIB_OBJS = @shlib_objs@ % ldconfig -r | grep gcc_ 6:-lgcc_s.1 => /lib/libgcc_s.so.1 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 766:-lgcc_s.2 => /usr/local/lib/gcc6/libgcc_s.so.2 % gfortran6 -o z h.f90 % ./z hello % ldd z z: libgfortran.so.3 => /usr/local/lib/gcc6/libgfortran.so.3 (0x200645000) libm.so.5 => /lib/libm.so.5 (0x20096c000) libgcc_s.so.2 => /usr/local/lib/gcc6/libgcc_s.so.2 (0x2009a) libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200bb7000) libc.so.7 => /lib/libc.so.7 (0x200df7000) This works for this particular name conflict. Hopefully, FreeBSD never needs to bump /lib/libgcc_s.so.1 to /lib/libgcc_s.so.2. This, however, introduces an incompatibility with what is actually distributed by GCC. Finally, can people stop referring to the above error as "gfortran's FreeBSD issue". This is a FreeBSD runtime loader issue. -- Steve ___ 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"
Re: math/suitesparse is broken
On Tue, May 01, 2018 at 02:57:16PM +1000, Dewayne Geraghty wrote: > Thanks Steve, I have the same problem via gcc7 (after giving up on > clang6). You might get a response to a PR. Sadly I > just reverted both /usr/src and suitesparse, and moved on... > as there are other problems with i386 and I suspect amd64. > > gcc7 -pie -Wl,--strip-debug -Wl,--build-id=md5 > -Wl,-rpath=/usr/local/lib/gcc7 -L/usr/local/lib/gcc7 -B/usr/local/bin (snip) > -L/usr/local/lib/gcc7 -llapack -lopenblas > /usr/local/bin/ranlib libcholmod.a > /usr/lib/Scrt1.o: In function `_start': > /smallblocks/src/lib/csu/amd64/crt1.c:(.text+0x18c): undefined reference > to `main' > collect2: error: ld returned 1 exit status > gmake[4]: *** [Makefile:544: Dewayne, Once I found a way to defeat openblas, my build of suitesparse completed without the above issue. I'm running a few day old -current, so there may be something the needs to get merged into the 11 branch. -- Steve ___ 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"
Re: math/suitesparse is broken
On Tue, May 01, 2018 at 08:39:42AM +0200, Rainer Hurling wrote: > Am 01.05.2018 um 05:40 schrieb Steve Kargl: > > Can someone fix math/suitesparse? > > > > % make config > > > > > > % make > > ... > > > > h/suitesparse/work/SuiteSparse/lib/libcholmod.so.3.0.12 -lm -lamd -lcolamd > > -lsuitesparseconfig -lccolamd -lcamd -L/usr/local/lib -lmetis > > -Wl,-rpath=/usr/local/lib/gcc7 -L/usr/local/lib/gcc7 -B/usr/local/bin > > -L/usr/local/lib -fstack-protector -Wl,-rpath=/usr/local/lib/gcc7 > > -L/usr/local/lib/gcc7 -llapack -lopenblas > > /usr/local/bin/ld: cannot find -lopenblas > > collect2: error: ld returned 1 exit status > > gmake[5]: *** [Makefile:544: > > /usr/ports/math/suitesparse/work/SuiteSparse/lib/libcholmod.so.3.0.12] > > Error 1 > > gmake[5]: Leaving directory > > '/usr/ports/math/suitesparse/work/SuiteSparse/CHOLMOD/Lib' > > gmake[4]: *** [Makefile:31: library] Error 2 > > gmake[4]: Leaving directory > > '/usr/ports/math/suitesparse/work/SuiteSparse/CHOLMOD/Lib' > > gmake[3]: *** [Makefile:14: all] Error 2 > > gmake[3]: Leaving directory > > '/usr/ports/math/suitesparse/work/SuiteSparse/CHOLMOD' > > gmake[2]: *** [Makefile:21: go] Error 2 > > gmake[2]: Leaving directory '/usr/ports/math/suitesparse/work/SuiteSparse' > > *** Error code 2 > > > > openblas is not Netlib BLAS. > > > > Hi Steve, > > For this error it should be sufficient to deinstall the old port. > before you build and install the new one. In some cases, there are > further breaks [1]. > It is uninstalled. Transitioning from perl 5.24 to 5.26 caused numerous ports to be deleted. I've looked at the files in math/suitesparse/work. This port now requires openblas as there is a hardcoded -lopenblas in one of its *.mk files or one needs to manually edit *.mk. % cd work % find . -type f | xargs grep lopenblas % nedit ./SuiteSparse_shared/SuiteSparse_config/SuiteSparse_config.mk % cd .. % make % make install -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ 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"
math/suitesparse is broken
Can someone fix math/suitesparse? % make config % make ... h/suitesparse/work/SuiteSparse/lib/libcholmod.so.3.0.12 -lm -lamd -lcolamd -lsuitesparseconfig -lccolamd -lcamd -L/usr/local/lib -lmetis -Wl,-rpath=/usr/local/lib/gcc7 -L/usr/local/lib/gcc7 -B/usr/local/bin -L/usr/local/lib -fstack-protector -Wl,-rpath=/usr/local/lib/gcc7 -L/usr/local/lib/gcc7 -llapack -lopenblas /usr/local/bin/ld: cannot find -lopenblas collect2: error: ld returned 1 exit status gmake[5]: *** [Makefile:544: /usr/ports/math/suitesparse/work/SuiteSparse/lib/libcholmod.so.3.0.12] Error 1 gmake[5]: Leaving directory '/usr/ports/math/suitesparse/work/SuiteSparse/CHOLMOD/Lib' gmake[4]: *** [Makefile:31: library] Error 2 gmake[4]: Leaving directory '/usr/ports/math/suitesparse/work/SuiteSparse/CHOLMOD/Lib' gmake[3]: *** [Makefile:14: all] Error 2 gmake[3]: Leaving directory '/usr/ports/math/suitesparse/work/SuiteSparse/CHOLMOD' gmake[2]: *** [Makefile:21: go] Error 2 gmake[2]: Leaving directory '/usr/ports/math/suitesparse/work/SuiteSparse' *** Error code 2 openblas is not Netlib BLAS. -- Steve ___ 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"
Re: Conflicts due to renamed KDE4 ports
On Sat, Apr 14, 2018 at 02:30:09PM +, Carmel NY wrote:
> On Sat, 14 Apr 2018 14:18:22 +0200, Stefan Esser stated:
>
> {truncated}
>
> >This is another case (after the implementation of FLAVOR support that does
> >not seem well-designed and causes lots of effort and inefficiencies in port
> >management tools like portmaster), which makes me consider giving up my
> >efforts to keep portmaster alive.
>
> Have you tried using "synth"?
This discussion occurred with the introduction of FLAVORS,
which broken all ports management tools except poudriere.
--
Steve
___
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"
Re: Committer help needed with math/octave
On Fri, Feb 23, 2018 at 06:43:47PM +, Montgomery-Smith, Stephen wrote: > Let me do it. I'm not at my FreeBSD computer right now, and > I don't remember my committer password. Thanks! -- Steve ___ 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"
Committer help needed with math/octave
Per Maho's request can someone please commit the patch at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225073 Maho has also asked to be dropped as maintainer. -- Steve ___ 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"
Re: Use of undeclared identifier 'fpgetmask'
On Mon, Jan 22, 2018 at 08:48:48AM -0800, bob prohaska wrote: > > What happens if you force inclusion by deleting #ifdef HAVE_IEEEFP_H? > > > After commenting out the test, running make clean and restarting a single- > threaded make the process stops with the same error: > > src/main.cpp:679:15: error: use of undeclared identifier 'fpgetmask' > fpsetmask(fpgetmask() & ~(FP_X_DZ | FP_X_INV)); > > > I've placed a copy of the make log file at > http://www.zefox.net/~fbsd/rpi2/inkscape/ieeefp_h_included.log > rpi2 is an ARM based board, right? Compare /usr/src/sys/amd64/include/ieeefp.h /usr/src/sys/arm/include/ieeefp.h It seems that FreeBSD' ARM architecture doesn't implement the functions associate with ieeefp.h. You probably need to force HAVE_IEEEF_H to 0. -- Steve ___ 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"
Re: Use of undeclared identifier 'fpgetmask'
On Sun, Jan 21, 2018 at 08:01:30AM -0800, bob prohaska wrote: > On Sat, Jan 20, 2018 at 03:04:21PM -0800, Steve Kargl wrote: > > On Sat, Jan 20, 2018 at 02:26:38PM -0800, bob prohaska wrote: > > > > > > use of undeclared identifier 'fpgetmask' > > > > > > > > > > > > > man fpsetmask > > > > Add "#include " to your code. > > > > Sorry, I chopped off the preamble 8-( > > This is in reference to /usr/ports/graphics/inkscape. > > Inkscape has lots of dependencies, so knowing where to make a > change is difficult. With luck it'll be a config option. > > I've put the make log at > http://www.zefox.net/~fbsd/rpi2/inkscape/ > > Thanks for reading, and any ideas! > It looks like that you'll need to read main.cpp to see if ieeefp.h is properly included in the file. Are there any #ifdef HAVE_IEEE #endif blocks preventing ieeefp.h from being found. -- Steve ___ 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"
Re: Use of undeclared identifier 'fpgetmask'
On Sun, Jan 21, 2018 at 09:58:40AM -0800, bob prohaska wrote: > > Main.cpp contains a test: > > #ifdef HAVE_IEEEFP_H > #include > #endif > > and, in /usr/ports/graphics/inkscape/work/inkscape-0.92.2/include/config.h is > found > > /* Define to 1 if you have the header file. */ > #define HAVE_IEEEFP_H 1 > > so it looks as if the test is satisfied. > > A brute-force search of the filesystem discloses several copies of ieeefh.h: > /tmp/mountpoint.Jw2teE/www/firefox-esr/work/firefox-52.5.2esr/obj-armv7-unknown-freebsd12.0/config/system_wrappers/ieeefp.h > /usr/include/machine/ieeefp.h > /usr/include/ieeefp.h Does this include fpgetmask and does the compiler include -I/usr/include in its command line? Is config.h included in main.cpp? > Thanks for reading, and any further thoughts! What happens if you force inclusion by deleting #ifdef HAVE_IEEEFP_H? -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ 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"
Re: Use of undeclared identifier 'fpgetmask'
On Sat, Jan 20, 2018 at 02:26:38PM -0800, bob prohaska wrote: > > use of undeclared identifier 'fpgetmask' > > A web search for the phrase finds a very few references, most prominently > from the year 2014: > https://www.where-i-go.com/tag/fpsetmask > but the context is different (mysql server). > > There is a workaround detailed in the web page, but after nearly four > years it's hard to believe that's still appropriate. > > Is there a more up-to-date solution? > > Thanks for reading, > > bob prohaska > man fpsetmask Add "#include " to your code. -- Steve ___ 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"
Re: py27 ports always show "new version available"
On Sun, Jan 07, 2018 at 04:23:08AM +, Tatsuki Makino wrote:
> Hello.
>
> Are your portmaster outputting the following message?
>
> make: "/usr/ports/Mk/bsd.port.mk" line 1067: FLAVOR may not be
> passed empty as a make argument.
>
> When I tried portmaster -i cmake, portmaster always tries to update
> textproc/py-sphinx.
Yes, that's the message I was seeing. With deve/flang, I was getting
the same message for py-enum34, too. It was a comedy of errors.
here:
portmaster -Byd devel/flang ! Dies due to trying to upgrade py-enum34
pkg delete py-enum34
portmaster -Byd devel/flang ! Installs py-enum34 and dies due to py-sphinx
pkg delete py-sphinx
goto here
pkg delete py-enum34 py-sphinx
portmaster -Byd devel/flang
goto here.
pkg delete py-enum34 py-sphinx
cd devel/flang
make
make install
make clean
> It seems that it occurred because function iport_from_origin returned 1.
> I surveyed with grep -r -e textproc/py-sphinx --include '*/Makefile*'
> /usr/ports. textproc/py-sphinx, textproc/py-sphinx@${FLAVOR}, and
> textproc/py-sphinx@${PY_FLAVOR} are mixed in the variable of *_DEPENDS.
> cmake is textproc/py-sphinx.
I haven't the patiences to wade through ports/Mk. I just accept the
fact that a decision was made that breaks in-place upgrading of ports.
--
Steve
___
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"
Re: py27 ports always show "new version available"
On Fri, Jan 05, 2018 at 10:50:11AM -0600, Rob Belics wrote: > I'm sure I caused this problem when FLAVORS came out by trying to set a > FLAVOR using "make". Using portmaster as I always have, py27-cffi and > py27-setuptools update to the latest version that portsnap downloads but > checking for new versions always returns "new version available" even after > updating. > > portmaster -L --index-only | egrep '(ew|ort) version|total install' > ===>>> New version available: py27-cffi-1.11.2 > ===>>> New version available: py27-setuptools-38.2.5 > > Trying to remove the port with portmaster, pkg or 'make' and > reinstalling does not change anything. > Saw the same abysmal situation yesterday with devel/flang. The ports system wanted to update py27-enum34-1.1.6 and py27-sphinx-1.4.8_2,1. After 'pkg delete XXX' of the offending ports, portmaster would install the ports, then promptly fail installing devel/flang because new versions were available and installation of new versions failed because, well, the py27-XXX ports were already installed. I had to resort to the good old-fashion 'cd devel/flang; make && make install && make clean' and even this method failed a few attempts. :( -- Steve ___ 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"
Re: Procmail Vulnerabilities check
On Sun, Dec 10, 2017 at 01:21:13PM +, Matthew Seaman wrote: > > Hence the current sendmail in base is neither fish nor fowl: way > overpowered for almost all installations, but with significant > limitations for a machine providing a full-blown mail service. > Personally I agree with his reasoning: unless the primary function of > your FreeBSD machine is to be an MTA, you really don't need any more > capability than to either deliver to a local mailbox, or forward all > e-mails to a smart host. Certainly you don't need anything capable of > receiving incoming e-mails. > I disagree. FreeBSd used to pride itself on being a complete operating system oout-of-the-box. Lately, a smaller number of developers are moving FreeBSD to being a kernel with a bunch of add-on software. dma(1) does not support a .forward file and by extension vacation(1). Without .forward, then those of use who use procmail(1) (subject of this email thread) in .forward and by extension spamassisin are hosed. Chapter 27 of the FreeBSD Handbook would need to be rewritten before sendmail can be removed. It is assumed that sendmail is installed with base. -- Steve ___ 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"
Re: Procmail Vulnerabilities check
On Sat, Dec 09, 2017 at 10:16:54AM +1100, Dave Horsfall wrote: > On Fri, 8 Dec 2017, Steve Kargl wrote: > > > First, there is movement afoot to remove sendmail from FreeBSD and > > replace it with dma(1). > > There is? Is there anything else that they're going to spring on us? > https://lists.freebsd.org/pipermail/freebsd-arch/2017-December/018712.html FreeBSD use to pride itself on being a complete (unix-like) operating system out-of-box. -- Steve ___ 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"
