Re: Problem building Openoffice 3.1.1 at -current
Can you guys trim your CC list? I have no interest in the stupidity of OOo in including every project under the sun into its build system. -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Correct __FreeBSD_version to use?
I use FreeBSD mainline for my normal use and I don't have
access to a system with the upcoming FreeBSD 8.0. It appears
the changes to sys/amd64/include/pcb.h to remove the
pcb_{fs,ds,es,gs} members of the pcb struct breaks at least
gdb-6.8.x and gdb-7.0. I've sent a patch to the gdb developers
to get gdb-7.0 building on FreeBSD mainline.
--- amd64fbsd-nat.c.orig2009-10-12 14:38:56.0 -0700
+++ amd64fbsd-nat.c 2009-10-12 14:40:13.0 -0700
@@ -95,6 +95,7 @@
#include
#include
+#include
#include "bsd-kvm.h"
@@ -123,10 +124,12 @@
regcache_raw_supply (regcache, 13, &pcb->pcb_r13);
regcache_raw_supply (regcache, 14, &pcb->pcb_r14);
regcache_raw_supply (regcache, 15, &pcb->pcb_r15);
+#if (__FreeBSD_version < 90)
regcache_raw_supply (regcache, AMD64_DS_REGNUM, &pcb->pcb_ds);
regcache_raw_supply (regcache, AMD64_ES_REGNUM, &pcb->pcb_es);
regcache_raw_supply (regcache, AMD64_FS_REGNUM, &pcb->pcb_fs);
regcache_raw_supply (regcache, AMD64_GS_REGNUM, &pcb->pcb_gs);
+#endif
return 1;
}
My question is what __FreeBSD_version number should I use
to have gdb working on FreeBSD 8.0 or greater? To be clear,
this is the commit to the 8.0 branch that breaks anything
that uses pcb on the amd64 target.
http://svn.freebsd.org/viewvc/base/stable/8/sys/amd64/include/pcb.h?view=log
Revision 190620 - (view) (annotate) - [select for diffs]
Modified Wed Apr 1 13:09:26 2009 UTC (6 months, 2 weeks ago) by kib
Original Path: head/sys/amd64/include/pcb.h
File length: 3319 byte(s)
Diff to previous 189903
--
Steve
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Correct __FreeBSD_version to use?
On Thu, Oct 15, 2009 at 08:27:15PM +, b. f. wrote: > >My question is what __FreeBSD_version number should I use > >to have gdb working on FreeBSD 8.0 or greater? > > The earliest FreeBSD version bump after Revision 190620, Wed Apr 1 > 13:09:26 2009 UTC, seems to have been in Revision 190787, Mon Apr 6 > 22:29:41 2009 UTC, which changed the version to 800075: > > http://svn.freebsd.org/viewvc/base/head/sys/sys/param.h?r1=190373&r2=190787 > > b. Thanks. I'll update my patch and forward it to the gdb developers. -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re-organizing the directory hierarchy?
Has portmgr considered a re-organization of the current
directory structure for ports?
troutmask:root[226] pwd
/usr/ports/devel
troutmask:root[227] ls | wc -l
3633
troutmask:root[228] ls | grep -E ^p5- | wc -l
1446
troutmask:root[229] ls | grep -E ^py- | wc -l
275
troutmask:root[230] ls | grep -E ^ruby- | wc -l
53
Having 1446 perl5 related directories sitting
under ports/devel seems silly, and prevents
one from using ls to quick scan ports/devel
for diffent ports.
How about adding ports/perl5, ports/python, ports/ruby?
One can then categorize, for example, the various p5-*
under an appropriate subdir ports/perl5/{math|www|mail}
--
Steve
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
lang/gcc broken
Can someone please fix the lang/gcc port for FreeBSD-current? The weekly churn is lang/gcc46 gave me the brilliant idea to switch over to lang/gcc. What a $#@! nightmare! The only nightmare that surpasses the current lang/gcc fiasco is the questionable churn in lang/gcc46. -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[PATCH] lang/gcc -- Fix build on freebsd-current
diff -ur gcc-4.6.2.orig/boehm-gc/configure gcc-4.6.2/boehm-gc/configure
--- gcc-4.6.2.orig/boehm-gc/configure 2011-10-26 02:30:24.0 -0700
+++ gcc-4.6.2/boehm-gc/configure2011-12-16 11:19:53.0 -0800
@@ -10520,7 +10520,7 @@
objformat=`/usr/bin/objformat`
else
case $host_os in
-freebsd[123]*) objformat=aout ;;
+freebsd[23]*) objformat=aout ;;
*) objformat=elf ;;
esac
fi
@@ -12428,7 +12428,7 @@
esac
;;
- freebsd[12]*)
+ freebsd2*)
# C++ shared libraries reported to be fairly broken before
# switch to ELF
ld_shlibs_CXX=no
@@ -14203,7 +14203,7 @@
objformat=`/usr/bin/objformat`
else
case $host_os in
-freebsd[123]*) objformat=aout ;;
+freebsd[23]*) objformat=aout ;;
*) objformat=elf ;;
esac
fi
diff -ur gcc-4.6.2.orig/configure gcc-4.6.2/configure
--- gcc-4.6.2.orig/configure2011-06-27 13:54:59.0 -0700
+++ gcc-4.6.2/configure 2011-12-16 11:19:03.0 -0800
@@ -3126,7 +3126,7 @@
noconfigdirs="$noconfigdirs sim target-rda"
noconfigdirs="$noconfigdirs ${libgcj}"
;;
- *-*-freebsd[12] | *-*-freebsd[12].* | *-*-freebsd*aout*)
+ *-*-freebsd2 | *-*-freebsd2.* | *-*-freebsd*aout*)
noconfigdirs="$noconfigdirs target-newlib target-libgloss ${libgcj}"
;;
*-*-freebsd*)
diff -ur gcc-4.6.2.orig/gcc/config.gcc gcc-4.6.2/gcc/config.gcc
--- gcc-4.6.2.orig/gcc/config.gcc 2011-07-22 09:44:50.0 -0700
+++ gcc-4.6.2/gcc/config.gcc2011-12-16 11:19:24.0 -0800
@@ -272,7 +272,7 @@
| pdp11-*-bsd \
| sparc-hal-solaris2* \
| thumb-*-* \
- | *-*-freebsd[12] | *-*-freebsd[12].* \
+ | *-*-freebsd2 | *-*-freebsd2.* \
| *-*-freebsd*aout* \
| *-*-linux*aout* \
| *-*-linux*coff* \
diff -ur gcc-4.6.2.orig/gcc/configure gcc-4.6.2/gcc/configure
--- gcc-4.6.2.orig/gcc/configure2011-10-12 11:07:25.0 -0700
+++ gcc-4.6.2/gcc/configure 2011-12-16 11:19:40.0 -0800
@@ -16653,7 +16653,7 @@
objformat=`/usr/bin/objformat`
else
case $host_os in
-freebsd[123]*) objformat=aout ;;
+freebsd[23]*) objformat=aout ;;
*) objformat=elf ;;
esac
fi
@@ -18537,7 +18537,7 @@
esac
;;
- freebsd[12]*)
+ freebsd2*)
# C++ shared libraries reported to be fairly broken before
# switch to ELF
ld_shlibs_CXX=no
@@ -20312,7 +20312,7 @@
objformat=`/usr/bin/objformat`
else
case $host_os in
-freebsd[123]*) objformat=aout ;;
+freebsd[23]*) objformat=aout ;;
*) objformat=elf ;;
esac
fi
diff -ur gcc-4.6.2.orig/libffi/configure gcc-4.6.2/libffi/configure
--- gcc-4.6.2.orig/libffi/configure 2011-10-26 02:30:24.0 -0700
+++ gcc-4.6.2/libffi/configure 2011-12-16 11:16:32.0 -0800
@@ -9914,7 +9914,7 @@
objformat=`/usr/bin/objformat`
else
case $host_os in
-freebsd[123]*) objformat=aout ;;
+freebsd[23]*) objformat=aout ;;
*) objformat=elf ;;
esac
fi
diff -ur gcc-4.6.2.orig/libgcc/config.host gcc-4.6.2/libgcc/config.host
--- gcc-4.6.2.orig/libgcc/config.host 2011-03-13 23:06:23.0 -0700
+++ gcc-4.6.2/libgcc/config.host2011-12-16 11:16:26.0 -0800
@@ -145,7 +145,7 @@
asm_hidden_op=.private_extern
tmake_file="t-darwin ${cpu_type}/t-darwin t-slibgcc-darwin"
;;
-*-*-freebsd[12] | *-*-freebsd[12].* | *-*-freebsd*aout*)
+*-*-freebsd2 | *-*-freebsd2.* | *-*-freebsd*aout*)
# This is the place-holder for the generic a.out configuration
# of FreeBSD. No actual configuration resides here since
# there was only ever a bare-bones ix86 configuration for
diff -ur gcc-4.6.2.orig/libgfortran/configure gcc-4.6.2/libgfortran/configure
--- gcc-4.6.2.orig/libgfortran/configure2011-10-26 02:30:24.0
-0700
+++ gcc-4.6.2/libgfortran/configure 2011-12-16 11:17:48.0 -0800
@@ -11242,7 +11242,7 @@
objformat=`/usr/bin/objformat`
else
case $host_os in
-freebsd[123]*) objformat=aout ;;
+freebsd[23]*) objformat=aout ;;
*) objformat=elf ;;
esac
fi
@@ -14870,7 +14870,7 @@
objformat=`/usr/bin/objformat`
else
case $host_os in
-freebsd[123]*) objformat=aout ;;
+freebsd[23]*) objformat=aout ;;
*) objformat=elf ;;
esac
fi
diff -ur gcc-4.6.2.orig/libgo/configure gcc-4.6.2/libgo/configure
--- gcc-4.6.2.orig/libgo/configure 2011-02-20 20:17:20.0 -0800
+++ gcc-4.6.2/libgo/configure 2011-12-16 11:17:25.0 -0800
@@ -10046,7 +10046,7 @@
objformat=`/usr/bin/objformat`
else
case $host_os in
-freebsd[123]*) objformat=aout ;;
+freebsd[23]*) objformat=aout ;;
*) objformat=elf ;;
esac
fi
diff -ur gcc-4.6.2.orig/libgomp/configure gcc-4.6.2/libgomp/configure
--- gcc-4.6.2.orig/libgomp/configure2011-10-
Re: [PATCH] lang/gcc -- Fix build on freebsd-current
On Fri, Dec 16, 2011 at 06:09:08PM -0800, Xin LI wrote: > > Actually you can add a dot (.) to these matches, e.g. freebsd[123]* -> > freebsd[123].*, etc... Have you contacted the maintainer > (ger...@freebsd.org) by the way? > There are probably a few different ways to workaround the problem. This is my 15 minute effort to get lang/gcc to build. gerald@ has indicated in another email thread that he'll probably backport GCC trunk's official patch. That's too much effort and too far out into the future for my immediate needs. -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [PATCH] lang/gcc -- Fix build on freebsd-current
On Fri, Dec 16, 2011 at 09:15:06PM -0600, Mark Linimon wrote: > On Fri, Dec 16, 2011 at 06:09:08PM -0800, Xin LI wrote: > > Actually you can add a dot (.) to these matches, e.g. freebsd[123]* -> > > freebsd[123].*, etc... Have you contacted the maintainer > > (ger...@freebsd.org) by the way? > > My guess? We should rip out the [123] and [23] strings entirely. If > anyone is running ports on FreeBSD 1, they have more problems than they > can count right now. > > I can personally guarantee that ports don't work on 4.x (I ripped out > the compat code several years ago that dealt with gross old make(1) > bugs, etc.) and I think that means not 3.x either. In any case, the > official claim is that the Ports Collection only supports 789 as first- > class citizens right now, not anything older. > gerald@ has indicated that he'll do something with the official GCC way to deal with 1. versus 10. This patch is a stop gap for others, who like me, will run into a broken lang/gcc while we wait for a better solution. -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [PATCH] lang/gcc -- Fix build on freebsd-current
On Mon, Dec 19, 2011 at 04:09:02PM +0900, Gerald Pfeifer wrote: > > As usual, Brendan is right on target. :-) If you guys would like > to test the attached patch for lang/gcc, it does allow that port > to build on a FreeBSD 10 system for me, and if I get independent > confirmation in the next three days it'll be in before holiday > season. Not sure why you need confirmation before committing if it works for you, because anything has to be better than the current state. > > Index: libgomp/ChangeLog > > === > > --- libgomp/ChangeLog (revision 181535) > > +++ libgomp/ChangeLog (revision 181536) > > @@ -1,3 +1,7 @@ > > +2011-11-20 Andreas Tobler > > + > > + * configure: Regenerate. > > + > > 2011-10-26 Release Manager > > > > * GCC 4.6.2 released. Why? Given that the typical build is 'make && make install && make clean', patching ChangeLog seems rather odd. The same question applies to the other ChangeLog diffs that I've removed. -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Please test your commits
Is there any reguirement that a ports committer needs to test their intended commit prior to pulling the trigger? http://www.freebsd.org/cgi/cvsweb.cgi/ports/print/ghostscript9/Makefile Committed 75 minutes ago. laptop:root[202] cd /usr/ports/print/ghostscript9 laptop:root[203] make In file included from openjpeg/libopenjpeg/bio.c:32: openjpeg/libopenjpeg/opj_includes.h:80:6: warning: "__STDC_VERSION__" is not defined In file included from openjpeg/libopenjpeg/opj_malloc.h:89, from openjpeg/libopenjpeg/opj_includes.h:108, from openjpeg/libopenjpeg/bio.c:32: /usr/include/malloc.h:3:2: error: #error " has been replaced by " gmake[2]: *** [soobj/opj_bio.o] Error 1 gmake[2]: Leaving directory `/usr/ports/print/ghostscript9/work/ghostscript-9.05' gmake[1]: *** [so-subtarget] Error 2 gmake[1]: Leaving directory `/usr/ports/print/ghostscript9/work/ghostscript-9.05' gmake: *** [so] Error 2 *** Error code 1 Stop in /usr/ports/print/ghostscript9. *** Error code 1 -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Please test your commits
On Sun, Feb 12, 2012 at 08:03:28PM +, Chris Rees wrote: > On 12 Feb 2012 19:39, "Steve Kargl" > wrote: > > > > Is there any reguirement that a ports committer needs > > to test their intended commit prior to pulling the > > trigger? > > > > Could this not have gone directly to the 'offending' developer? > You seem to have the faulty belief that this is the first occurence of this type of issue? portmgr should immediately revert the commit. In fact, after changing the source code to avoid the malloc.h issue, one runs into cp ./soobj/openjpeg_0.dev ./soobj/openjpeg.dev cc -DHAVE_MKSTEMP -DHAVE_FONTCONFIG -DHAVE_LIBIDN -DHAVE_SETLOCALE -DHAVE_SSE2 -DHAVE_DBUS -O2 -pipe -march=native -fno-strict-aliasing -g -fPIC -DUPD_SIGNAL=0 -I. -I/usr/ports/print/ghostscript9/work/ghostscript-9.05/lcms/include -I/usr/local/include/libpng -I/usr/local/include -I/usr/local/include/freetype2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin -fno-common -DHAVE_STDINT_H=1 -DHAVE_SYS_TIME_H=1 -DGX_COLOR_INDEX_TYPE="unsigned long long" -O2 -pipe -march=native -fno-strict-aliasing -DUSE_LIBICONV_GNU -I/usr/local/include -DGS_DEVS_SHARED -DGS_DEVS_SHARED_DIR=\"/usr/local/lib/ghostscript/9.05\" -Iopenjpeg/libopenjpeg/.. -Iopenjpeg/libopenjpeg -I./soobj -I./base -DUSE_OPENJPEG_JP2 -o ./soobj/sjpx_openjpeg.o \ -c -DOPJ_STATIC ./base/sjpx_openjpeg.c ./base/sjpx_openjpeg.c: In function 'decode_image': ./base/sjpx_openjpeg.c:169: error: too many arguments to function 'opj_decode' ./base/sjpx_openjpeg.c:205: error: 'opj_image_comp_t' has no member named 'typ' ./base/sjpx_openjpeg.c:205: error: 'CTYPE_COLOR' undeclared (first use in this function) ./base/sjpx_openjpeg.c:205: error: (Each undeclared identifier is reported only once ./base/sjpx_openjpeg.c:205: error: for each function it appears in.) ./base/sjpx_openjpeg.c:207: error: 'opj_image_comp_t' has no member named 'typ' ./base/sjpx_openjpeg.c:207: error: 'CTYPE_OPACITY' undeclared (first use in this function) ./base/sjpx_openjpeg.c:217: error: 'CLRSPC_CMYK' undeclared (first use in this function) ./base/sjpx_openjpeg.c:250: error: 'opj_image_t' has no member named 'has_palette' ./base/sjpx_openjpeg.c:257: error: 'CLRSPC_EYCC' undeclared (first use in this function) gmake[2]: *** [soobj/sjpx_openjpeg.o] Error 1 gmake[2]: Leaving directory `/usr/ports/print/ghostscript9/work/ghostscript-9.05' gmake[1]: *** [so-subtarget] Error 2 gmake[1]: Leaving directory `/usr/ports/print/ghostscript9/work/ghostscript-9.05' gmake: *** [so] Error 2 -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Please test your commits
On Sun, Feb 12, 2012 at 10:27:25PM +0200, Andriy Gapon wrote: > on 12/02/2012 22:16 Steve Kargl said the following: > > You seem to have the faulty belief that this is the first occurence > > of this type of issue? > > So instead of proper report to the port's maintainer (including description of > your environment, possibly full build log, etc), possibly with a CC here, you > decided to vent out here... > > Is there any requirement that people do the former and not the latter? :-) > I'm not venting. I'm simply requesting that all committers test the code that they intend to commit. It is quite clear that this particular commit was not tested. The environment is irrelevant because malloc.h was poisoned 10 years, 3 months ago. As to a full build log, the necessary information was included in my original email. -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Please test your commits
On Sun, Feb 12, 2012 at 08:44:11PM +, Chris Rees wrote: > On 12 Feb 2012 20:41, "Steve Kargl" > wrote: > > > > On Sun, Feb 12, 2012 at 10:27:25PM +0200, Andriy Gapon wrote: > > > on 12/02/2012 22:16 Steve Kargl said the following: > > > > You seem to have the faulty belief that this is the first occurence > > > > of this type of issue? > > > > > > So instead of proper report to the port's maintainer (including > description of > > > your environment, possibly full build log, etc), possibly with a CC > here, you > > > decided to vent out here... > > > > > > Is there any requirement that people do the former and not the latter? > :-) > > > > > > > I'm not venting. I'm simply requesting that all committers > > test the code that they intend to commit. It is quite > > clear that this particular commit was not tested. > > > > The environment is irrelevant because malloc.h was poisoned > > 10 years, 3 months ago. As to a full build log, the > > necessary information was included in my original email. > > uname -a? > > Please do this the proper way; as a developer yourself you should know > better. > laptop:root[252] uname -a FreeBSD laptop 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r230975M: Sat Feb 4 09:03:27 PST 2012 root@laptop:/usr/obj/usr/src/sys/MOBILE i386 -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Please test your commits
On Sun, Feb 12, 2012 at 08:52:56PM +, Chris Rees wrote: > On 12 Feb 2012 20:45, "Steve Kargl" > wrote: > > > > > > laptop:root[252] uname -a > > FreeBSD laptop 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r230975M: Sat Feb 4 > 09:03:27 PST 2012 root@laptop:/usr/obj/usr/src/sys/MOBILE i386 > > Well, that immediately shows that this is a 10.0 error, which means it's > almost certainly due to freebsd1* being matched in some configure script. > Empirical evidence suggests that ghostscript9 developers are using a newer version of the autotools. laptop:root[262] find . -name configure | xargs grep -i "freebsd\[1" | more ./lcms/configure:freebsd[123].*) objformat=aout ;; ./lcms/configure: freebsd[12].*) ./lcms/configure:freebsd[123].*) objformat=aout ;; ./lcms/configure:freebsd[123].*) objformat=aout ;; ./lcms/configure:freebsd[123].*) objformat=aout ;; ./freetype/builds/unix/configure:freebsd[123].*) objformat=aout ;; ./lcms2/configure:freebsd[123].*) objformat=aout ;; ./lcms2/configure: freebsd[12].*) ./lcms2/configure:freebsd[123].*) objformat=aout ;; laptop:root[263] find . -name configure | xargs grep -i "freebsd1" | more ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./freetype/builds/unix/configure:freebsd1.*) ./freetype/builds/unix/configure:freebsd1.*) ./lcms2/configure:freebsd1.*) ./lcms2/configure:freebsd1.*) The malloc issue will not appear on amd64 because the problematic code is #elif !defined(__amd64__) && !defined(__APPLE__) #define HAVE_MEMALIGN #include #endif with the obvious fix #elif !defined(__amd64__) && !defined(__APPLE__) && !defined(__FreeBSD__) #define HAVE_MEMALIGN #include #endif But, the 2nd issue with too many arguments in a function call is clearly evident on amd64 because I justed test that on FreeBSD 10. -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Please test your commits
On Sun, Feb 12, 2012 at 03:32:52PM -0600, Stephen Montgomery-Smith wrote: > > > >But, the 2nd issue with too many arguments in a function call is > >clearly evident on amd64 because I justed test that on FreeBSD 10. > > Yes. But the issue isn't whether someone else was correct in why the > port might or might not have built in a particular environment. > > The issue is whether you were too hasty in your initial accusation that > the committer didn't test their commit. And another issue is whether > you should apologize to them for attempting to publicly humiliate them. > I've now tested on i386 and amd64, and the port fails to build on both architectures. Given the code for the malloc.h failure, this port will fail on all non-amd64 platforms that freebsd runs (dating back FreeBSD 5.0). The evidence suggests that this commit was not tested. -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: print/ghostscript9 fix
On Mon, Feb 13, 2012 at 11:43:57AM +0900, Hiroki Sato wrote: > Hiroki Sato wrote > in <201202130231.q1d2vixp051...@repoman.freebsd.org>: > > hr> hrs 2012-02-13 02:31:18 UTC > hr> > hr> FreeBSD ports repository > hr> > hr> Modified files: > hr> print/ghostscript9 Makefile > hr> print/ghostscript9/files patch-base-Makefile.in > hr> Added files: > hr> print/ghostscript9/files patch-base-openjpeg.mak > hr> patch-openjpeg-libopenjpeg-opj_includes.h > hr> patch-openjpeg-libopenjpeg-opj_malloc.h > hr> Log: > hr> Add missing patches. This should fix build on !amd64 platforms. > > This commit should fix the build breakage in the openjpeg related > files. If the compile error still persists even after this, please > let me know. > laptop:root[207] uname -a FreeBSD laptop 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r230975M: Sat Feb 4 09:03:27 PST 2012 root@laptop:/usr/obj/usr/src/sys/MOBILE i386 cc -DHAVE_MKSTEMP -DHAVE_FONTCONFIG -DHAVE_LIBIDN -DHAVE_SETLOCALE -DHAVE_SSE2 -DHAVE_DBUS -O2 -pipe -march=native -fno-strict-aliasing -fPIC -DUPD_SIGNAL=0 -I. -I/usr/ports/print/ghostscript9/work/ghostscript-9.05/lcms/include -I/usr/local/include/libpng -I/usr/local/include -I/usr/local/include/freetype2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin -fno-common -DHAVE_STDINT_H=1 -DHAVE_SYS_TIME_H=1 -DGX_COLOR_INDEX_TYPE="unsigned long long" -O2 -pipe -march=native -fno-strict-aliasing -DUSE_LIBICONV_GNU -I/usr/local/include -DGS_DEVS_SHARED -DGS_DEVS_SHARED_DIR=\"/usr/local/lib/ghostscript/9.05\" -Iopenjpeg/libopenjpeg/.. -Iopenjpeg/libopenjpeg -I./soobj -I./base -DUSE_OPENJPEG_JP2 -ffast-math -DOPJ_STATIC -std=c99 -o ./soobj/sjpx_openjpeg.o \ -c -DOPJ_STATIC ./base/sjpx_openjpeg.c ./base/sjpx_openjpeg.c: In function 'decode_image': ./base/sjpx_openjpeg.c:169: error: too many arguments to function 'opj_decode' ./base/sjpx_openjpeg.c:205: error: 'opj_image_comp_t' has no member named 'typ' ./base/sjpx_openjpeg.c:205: error: 'CTYPE_COLOR' undeclared (first use in this function) ./base/sjpx_openjpeg.c:205: error: (Each undeclared identifier is reported only once ./base/sjpx_openjpeg.c:205: error: for each function it appears in.) ./base/sjpx_openjpeg.c:207: error: 'opj_image_comp_t' has no member named 'typ' ./base/sjpx_openjpeg.c:207: error: 'CTYPE_OPACITY' undeclared (first use in this function) ./base/sjpx_openjpeg.c:217: error: 'CLRSPC_CMYK' undeclared (first use in this function) ./base/sjpx_openjpeg.c:250: error: 'opj_image_t' has no member named 'has_palette' ./base/sjpx_openjpeg.c:257: error: 'CLRSPC_EYCC' undeclared (first use in this function) gmake[2]: *** [soobj/sjpx_openjpeg.o] Error 1 gmake[2]: Leaving directory `/usr/ports/print/ghostscript9/work/ghostscript-9.05' gm troutmask:root[207] uname -a FreeBSD troutmask.apl.washington.edu 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r230912: Thu Feb 2 10:40:37 PST 2012 ka...@troutmask.apl.washington.edu:/usr/obj/usr/src/sys/SPEW amd64 cc -DHAVE_MKSTEMP -DHAVE_FONTCONFIG -DHAVE_SETLOCALE -DHAVE_SSE2 -DHAVE_DBUS -O2 -pipe -march=opteron -fno-strict-aliasing -fPIC -DUPD_SIGNAL=0 -I. -I/usr/ports/print/ghostscript9/work/ghostscript-9.05/lcms/include -I/usr/local/include/libpng -I/usr/local/include -I/usr/local/include/freetype2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin -fno-common -DHAVE_STDINT_H=1 -DHAVE_SYS_TIME_H=1 -DGX_COLOR_INDEX_TYPE="unsigned long int" -O2 -pipe -march=opteron -fno-strict-aliasing -DUSE_LIBICONV_GNU -I/usr/local/include -DGS_DEVS_SHARED -DGS_DEVS_SHARED_DIR=\"/usr/local/lib/ghostscript/9.05\" -Iopenjpeg/libopenjpeg/.. -Iopenjpeg/libopenjpeg -I./soobj -I./base -DUSE_OPENJPEG_JP2 -ffast-math -DOPJ_STATIC -std=c99 -o ./soobj/sjpx_openjpeg.o \ -c -DOPJ_STATIC ./base/sjpx_openjpeg.c ./base/sjpx_openjpeg.c: In function 'decode_image': ./base/sjpx_openjpeg.c:169: error: too many arguments to function 'opj_decode' ./base/sjpx_openjpeg.c:205: error: 'opj_image_comp_t' has no member named 'typ' ./base/sjpx_openjpeg.c:205: error: 'CTYPE_COLOR' undeclared (first use in this function) ./base/sjpx_openjpeg.c:205: error: (Each undeclared identifier is reported only once ./base/sjpx_openjpeg.c:205: error: for each function it appears in.) ./base/sjpx_openjpeg.c:207: error: 'opj_image_comp_t' has no member named 'typ' ./base/sjpx_openjpeg.c:207: error: 'CTYPE_OPACITY' undeclared (first use in this function) ./base/sjpx_openjpeg.c:217: error: 'CLRSPC_CMYK' undeclared (first use in this function) ./base/sjpx_openjpeg.c:250: error: 'opj_image_t' has no member named 'has_palette' ./base/sjpx_openjpeg.c:257: error: 'CLRSPC_EYCC' undeclared (first use in this
rtld or lang/gcc cannot find libgcc_s.so.1
Sorry about the cross post, but I can't tell if this a -current issue of a -ports issue. Unfortunately, I updated my freebsd 10.0 systems and the lang/gcc port during the same timeframe. I have compiled my math library and several programs with gfortran, which is installed by lang/gcc (pkg_info shows gcc-4.6.2_1). When I try running the program I get troutmask:kargl[210] halfspace /lib/libgcc_s.so.1: version GCC_4.6.0 required by /home/kargl/bin/halfspace not foundtroutmask:kargl[211] (Note, the annoying absense of a newline character after the error message, which is a completely different issue.) I see this problem on both freebsd-i386 and freebsd-amd64. troutmask:kargl[212] ldd ~/bin/halfspace /home/kargl/bin/halfspace: liblapack.so.4 => /usr/local/lib/liblapack.so.4 (0x2008c3000) libblas.so.2 => /usr/local/lib/libblas.so.2 (0x201463000) libgfortran.so.3 => /usr/local/lib/gcc46/libgfortran.so.3 (0x20175d000) libm.so.5 => /lib/libm.so.5 (0x201a7) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x201c95000) libquadmath.so.0 => /usr/local/lib/gcc46/libquadmath.so.0 (0x201ea2000) libc.so.7 => /lib/libc.so.7 (0x2020d6000) troutmask:kargl[212] ldconfig -r | grep libgcc_s 29:-lgcc_s.1 => /lib/libgcc_s.so.1 723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1 So, it appears that rtld is finding the wrong libgcc_s.so.1 or the lang/gcc port is no longer providing sufficient information for rtld to choose the correct library. I have reverted revisions 230784, 299768, and 229508 (and various combinitions of these revisions) from rtld-elf. The result does not change the above error. I can work around the problem by specifying -static during the building of my programs. Or, I can work around the problem by *explicitly* adding '-rpath /usr/local/lib' to the command line, which I have never had to do. -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, Feb 21, 2012 at 08:57:54PM +0200, Konstantin Belousov wrote: > On Tue, Feb 21, 2012 at 10:28:50AM -0800, Steve Kargl wrote: > > > > troutmask:kargl[210] halfspace > > /lib/libgcc_s.so.1: version GCC_4.6.0 required by /home/kargl/bin/halfspace > > not foundtroutmask:kargl[211] > > > > (Note, the annoying absense of a newline character after the error > > message, which is a completely different issue.) > > > > I see this problem on both freebsd-i386 and freebsd-amd64. > > > > troutmask:kargl[212] ldd ~/bin/halfspace > > /home/kargl/bin/halfspace: > > liblapack.so.4 => /usr/local/lib/liblapack.so.4 (0x2008c3000) > > libblas.so.2 => /usr/local/lib/libblas.so.2 (0x201463000) > > libgfortran.so.3 => /usr/local/lib/gcc46/libgfortran.so.3 > > (0x20175d000) > > libm.so.5 => /lib/libm.so.5 (0x201a7) > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x201c95000) > > libquadmath.so.0 => /usr/local/lib/gcc46/libquadmath.so.0 > > (0x201ea2000) > > libc.so.7 => /lib/libc.so.7 (0x2020d6000) > > troutmask:kargl[212] ldconfig -r | grep libgcc_s > > 29:-lgcc_s.1 => /lib/libgcc_s.so.1 > > 723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1 > > > > So, it appears that rtld is finding the wrong libgcc_s.so.1 or > > the lang/gcc port is no longer providing sufficient information > > for rtld to choose the correct library. > > > > I have reverted revisions 230784, 299768, and 229508 (and > > various combinitions of these revisions) from rtld-elf. The > > result does not change the above error. > > > > I can work around the problem by specifying -static during > > the building of my programs. Or, I can work around the > > problem by *explicitly* adding '-rpath /usr/local/lib' to the > > command line, which I have never had to do. > > > I highly suspect that you just happen to not need a symbol from the > newest namespace before. > > The thing to look first is the library search path in the ld.so hints, > which is output at the second line of ldconfig -r. I think that you have > /lib before /usr/local/lib/gcc46 in your setup. This guess is confirmed > by the numeration of the two instances of gcc_s above. Either change > the config, or use -rpath. AFAIR, ldconfig -m adds the directory > at the end of the search list. Yes, /lib comes before /usr/local/lib/gcc46. I suppose that this is a heads up for gerald@. lang/gcc is used by the ports collections to build a large number of other ports, so others are likely to hit this issue. I tried reading rtld.c to see where the issue lies. One possibility seems to be a change in rtld.c (lines 4012-13) to remember the version mismatch, then continuing the search to see if another library with the same name but different location matches. After exhausting the list of directories in the search path, either an error is reported or a match has been found. Note, I'm still trying to parse and understand the rtld.c code, so may be what I'm suggesting is not feasible. -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote:
> On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote:
> > On 2012-02-21 20:42, Steve Kargl wrote:
> > ...
> > > Yes, /lib comes before /usr/local/lib/gcc46. I suppose
> > > that this is a heads up for gerald@. lang/gcc is used by
> > > the ports collections to build a large number of other
> > > ports, so others are likely to hit this issue.
>
> Does -rpath not help ?
I already mentioned that I can add '-rpath /usr/local/lib/gcc46'
to my various projects. I can also build with -static to avoid
rtld. One can also use LD_LIBRARY_PATH.
The issue seems to be that lang/gcc will be installed after
system start, and 'ldconfig -m' appends new shared libraries
to the hints file. This means that libraries with the same
name but different locations will be found via the order of the
search path in the hints file, and one gets the wrong library.
That is, with the following
troutmask:root[256] ldconfig -r | grep libgcc_s
29:-lgcc_s.1 => /lib/libgcc_s.so.1
723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1
29 will be found before 723. While I can work around the
issue, lang/gcc is used by a rather large boatload of ports
during the building process and I suspect that a large
number of FreeBSD users use lang/gcc for their everyday
compiler. The question is how do we, the FreeBSD project,
deal with this issue, so that the general user base does not
get hit with it.
There are a few solutions:
1) Set ldconfig_paths in /etc/rc.conf to cause ${PORTSDIR}/lib to
be scanned before /lib and /usr/lib.
2) Use /etc/ld.so.conf to cause ${PORTSDIR}/lib to be scanned
for /lib and /usr/lib.
3) Add a new option to ldconfig to prepend new libraries to
the hints files and fix the ports to use this option instead
of -m.
4) Suggestions from people that are brighter than I.
--
Steve
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Wed, Feb 22, 2012 at 12:22:50AM +0100, Mel Flynn wrote: > On 2/21/2012 23:32, Steve Kargl wrote: > > On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote: > >> On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote: > >>> On 2012-02-21 20:42, Steve Kargl wrote: > >>> ... > >>>> Yes, /lib comes before /usr/local/lib/gcc46. I suppose > >>>> that this is a heads up for gerald@. lang/gcc is used by > >>>> the ports collections to build a large number of other > >>>> ports, so others are likely to hit this issue. > >> > >> Does -rpath not help ? > > > > I already mentioned that I can add '-rpath /usr/local/lib/gcc46' > > to my various projects. I can also build with -static to avoid > > rtld. One can also use LD_LIBRARY_PATH. > > Make sure it's your binary pulling in libgcc_s. I just went through a > few iterations of recompiling mplayer with different *FLAGS and each > time base gcc_s was pulled in. I then did an ldd -a `which mplayer` and > saw libschroedinger was the one actually pulling it in. > I already did the ldd song and dance. -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, Feb 21, 2012 at 06:39:36PM -0500, Daniel Eischen wrote:
> On Tue, 21 Feb 2012, Steve Kargl wrote:
>
> >On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote:
> >>On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote:
> >>>On 2012-02-21 20:42, Steve Kargl wrote:
> >>>...
> >>>>Yes, /lib comes before /usr/local/lib/gcc46. I suppose
> >>>>that this is a heads up for gerald@. lang/gcc is used by
> >>>>the ports collections to build a large number of other
> >>>>ports, so others are likely to hit this issue.
> >>
> >>Does -rpath not help ?
> >
> >I already mentioned that I can add '-rpath /usr/local/lib/gcc46'
> >to my various projects. I can also build with -static to avoid
> >rtld. One can also use LD_LIBRARY_PATH.
> >
> >The issue seems to be that lang/gcc will be installed after
> >system start, and 'ldconfig -m' appends new shared libraries
> >to the hints file. This means that libraries with the same
> >name but different locations will be found via the order of the
> >search path in the hints file, and one gets the wrong library.
> >That is, with the following
> >
> >troutmask:root[256] ldconfig -r | grep libgcc_s
> > 29:-lgcc_s.1 => /lib/libgcc_s.so.1
> > 723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1
> >
> >29 will be found before 723. While I can work around the
> >issue, lang/gcc is used by a rather large boatload of ports
> >during the building process and I suspect that a large
> >number of FreeBSD users use lang/gcc for their everyday
> >compiler. The question is how do we, the FreeBSD project,
> >deal with this issue, so that the general user base does not
> >get hit with it.
> >
> >There are a few solutions:
> >1) Set ldconfig_paths in /etc/rc.conf to cause ${PORTSDIR}/lib to
> > be scanned before /lib and /usr/lib.
> >2) Use /etc/ld.so.conf to cause ${PORTSDIR}/lib to be scanned
> > for /lib and /usr/lib.
>
> s/for/before/ ??
yes. sorry about the typo.
>
> >3) Add a new option to ldconfig to prepend new libraries to
> > the hints files and fix the ports to use this option instead
> > of -m.
>
> You don't want system binaries that want /lib/libgcc_s.so.1
> to use /usr/local/lib/gccXX/libgcc_s.so.1, though. Wouldn't
> your option 3 do that?
Well, yes, I suppose that could be a problem. :)
> >4) Suggestions from people that are brighter than I.
>
> [Not brighter than you, but]
>
> o For our system libgcc, use libcc_s.so.1 (or some other
> name) instead of libgcc_s.so.1?
Interesting idea. Perhaps, the port should install libgcc46_s.so.1,
and binaries installed by lang/gcc updated to use this library.
> o Change affected ports to use -rpath when building?
I started to look into this option, but it quickly becomes
apparent that some (evil) configure hackery may be needed.
--
Steve
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
QT4 appears to be broken
I thought I would try out libreoffice. So, as root I did cd /usr/opt ln -s /usr/opt /opt csup ~/supfile.ports cd /use/ports make fetchindex cd /usr/ports/editors/libreoffice make PREFIX=/opt/ ===> Installing for qt4-qmake-4.7.3 ===> Generating temporary packing list ===> Checking if devel/qmake4 already installed mkdir -p "/opt//share/qt4" cp -Rp /usr/ports/devel/qmake4/work/qt-everywhere-opensource-src-4.7.3/mkspecs /opt//share/qt4 install -s -o root -g wheel -m 555 qmake-qt4 /opt//bin /bin/ln -sf /opt//share/qt4/mkspecs/freebsd-g++ /opt//share/qt4/mkspecs/default ===> Registering installation for qt4-qmake-4.7.3 ===> Returning to build of qt4-moc-4.7.3 ===> Configuring for qt4-moc-4.7.3 /usr/bin/sed -i.bak -e 's|target.path.*|target.path=/opt//bin|g' -e 's|^TARGET.*|TARGET=moc-qt4|g' /usr/ports/devel/qt4-moc/work/qt-everywhere-opensource-src-4.7.3/src/tools/moc/moc.pro /bin/mkdir -p /usr/ports/devel/qt4-moc/work/qt-everywhere-opensource-src-4.7.3/mkspecs /bin/ln -sf /usr/local/bin/qmake-qt4 /usr/ports/devel/qt4-moc/work/qt-everywhere-opensource-src-4.7.3/bin/qmake The specified system/compiler is not supported: /usr/ports/devel/qt4-moc/work/qt-everywhere-opensource-src-4.7.3/mkspecs//usr/local/share/qt4/mkspecs/freebsd-g++ Please see the README file for a complete list. ===> Script "configure" failed unexpectedly. Please report the problem to k...@freebsd.org [maintainer] and attach the "/usr/ports/devel/qt4-moc/work/qt-everywhere-opensource-src-4.7.3/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). Please, fix. -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
PREFIX is not honored for dependencies
As root, I did mkdir -p /usr/opt ln -s /usr/opt /opt cd /usr/ports/editors/libreoffice make PREFIX=/opt/ The above builds and installs dependencies along the way under the /opt/ heirarchy. The first few are cppunit-1.12.1 mdbtools-0.5_14 boost-libs-1.45.0_1 The build finally dies with qt4-moc, because it does not honor PREFIX. I've attempted to work around the QT4 issue by patching its Makefile. So, I restart a build make clean make PREFIX=/opt/ This eventually dies with ===> Installing for cppunit-1.12.1 ===> Generating temporary packing list ===> Checking if devel/cppunit already installed ===> cppunit-1.12.1 is already installed You may wish to ``make deinstall'' and install this port again by ``make reinstall'' to upgrade it properly. If you really wish to overwrite the old port of devel/cppunit without deleting it first, set the variable "FORCE_PKG_REGISTER" in your environment or the "make install" command line. Of course, cppunit-1.12.1 is installed! The initial build in libreoffice installed it before qt4-moc crooked. Please fix. -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PREFIX is not honored for dependencies
On Sat, Aug 06, 2011 at 10:18:08AM +0100, Matthew Seaman wrote: > On 05/08/2011 23:08, Steve Kargl wrote: > > make clean > > make PREFIX=/opt/ > > > > This eventually dies with > > > > ===> Installing for cppunit-1.12.1 > > ===> Generating temporary packing list > > ===> Checking if devel/cppunit already installed > > ===> cppunit-1.12.1 is already installed > > You may wish to ``make deinstall'' and install this port again > > by ``make reinstall'' to upgrade it properly. > > If you really wish to overwrite the old port of devel/cppunit > > without deleting it first, set the variable "FORCE_PKG_REGISTER" > > in your environment or the "make install" command line. > > > > Of course, cppunit-1.12.1 is installed! The initial build > > in libreoffice installed it before qt4-moc crooked. > > You need to understand the effect of two different variables here: > > PREFIX--- where to install /this/ port > LOCALBASE --- where other ports have been installed > > PREFIX *only* affects where the current port will be installed. It > doesn't affect where this port looks for any dependencies. That's what > LOCALBASE is for. > man ports man make.conf man src.conf Hmmm, no description of LOCALBASE. So how is one to understand the difference? From 'man ports' PREFIXWhere to install things in general (usually /usr/local). I suppose that that 'in general' is not too 'in general'. I've pointed out elsewhere that cd /usr/ports/dev/cppunit make PREFIX=/opt/ install cd /usr/ports/editors/libreoffice make PREFIX=/opt/ does try to re-install cppunit; whereas if cppunit is not previously installed cd /usr/ports/editors/libreoffice make PREFIX=/opt/ installs and registers cppunit. If this dies and one restarts the make, then the make process tries to re-install cppunit. That's just poor design. -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Using stderr in an initialization?
I'm porting a piece of code to FreeBSD, and I've run into
a problem that I currently don't know how to solve. I scanned
both the Porter's Handbook and the Developer's Handbook, but
came up empty.
A reduce testcase is
#include
typedef FILE *FILEP;
static FILEP outfile = {stderr};
int
main(int argc, char *argv[])
{
FILE *fp;
if (argc == 2) {
fp = fopen(*++argv, "w");
outfile = fp;
}
fprintf(outfile, "Ouch!\n");
return 0;
}
GCC gives
troutmask:sgk[204] cc -o z a.c
a.c:5: error: initializer element is not constant
a.c:5: error: (near initialization for 'outfile')
Yes, I know in the simple example above that I could
put 'outfile = stderr' above the 'if (argc == 2)'
statement. In the much more complicated code, it isn't
clear where such a change be made. So, anyone have a
suggestion on how to change line 5 to satisfy gcc?
--
Steve
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using stderr in an initialization?
On Fri, May 02, 2008 at 01:43:55PM -0700, Bakul Shah wrote:
> On Fri, 02 May 2008 13:23:56 PDT Steve Kargl <[EMAIL PROTECTED]> wrote:
> > I'm porting a piece of code to FreeBSD, and I've run into
> > a problem that I currently don't know how to solve. I scanned
> > both the Porter's Handbook and the Developer's Handbook, but
> > came up empty.
> >
> > A reduce testcase is
> >
> > #include
> >
> > typedef FILE *FILEP;
> >
> > static FILEP outfile = {stderr};
> >
> ...
> > GCC gives
> >
> > troutmask:sgk[204] cc -o z a.c
> > a.c:5: error: initializer element is not constant
> > a.c:5: error: (near initialization for 'outfile')
> >
> > So, anyone have a
> > suggestion on how to change line 5 to satisfy gcc?
>
> It *used* to be the case that stderr was a macro referring to
> something like &_iob[2] which is a link time constant
> expression. As per section 7.19.1 in the C standard, the
> stderr macro is an expression of type `pointer to file' but
> not a constant. You wouldn't expect the following to work,
> would you?
>
> FILE* f;
> FILE* outfile = f;
>
> It is the exact same thing. But you can do
>
> static FILE** _outfile = &stderr;
> #define outfile (*_outfile)
>
> to achive the effect you want.
Thanks for the suggestion. This is K&R era code, and if
I read the dates in comments correctly, it predates the
formation of the ANSI C standard committee by more than
4 years.
--
Steve
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using stderr in an initialization?
On Sat, May 03, 2008 at 07:43:48AM +1000, Peter Jeremy wrote:
> On Fri, May 02, 2008 at 01:23:56PM -0700, Steve Kargl wrote:
> >static FILEP outfile = {stderr};
> ...
> >troutmask:sgk[204] cc -o z a.c
> >a.c:5: error: initializer element is not constant
> >a.c:5: error: (near initialization for 'outfile')
>
> The braces are superfluous but the underlying problem is that stderr
> is not a compile-time constant - it's an 'extern FILE *'.
>
> >clear where such a change be made. So, anyone have a
> >suggestion on how to change line 5 to satisfy gcc?
>
> Move the assignment to the start of main():
> >int
> >main(int argc, char *argv[])
> >{
> > FILE *fp;
> >
> outfile = stderr;
> > if (argc == 2) {
> ...
>
> If 'outfile' is not visible from main() then you'll need to use some
> sort of initialisation function - either called explicitly from main()
> or via an C++-style implicitly-called initialiser.
>
I chose the former although I'm not sure if that is the most
appropriate place. With this change (and few others) I have
successful built the Fortran 77 component of pcc (ie.,
ports/lang/pcc)
dhcp-78-86:kargl[206] cat h.f
program h
print *, 'Hello World!'
end
dhcp-78-86:kargl[207] ~/work/bin/f77 -v -O -o z h.f -L$HOME/work/lib
FORTRAN 77 DRIVER, VERSION 1.11, 28 JULY 1978
h.f:
MAIN h:
ASM.
LOAD.
dhcp-78-86:kargl[208] ./z
Hello World!
--
Steve
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[PATCH] Fix vtk-python port
--- Makefile2012-06-09 02:25:25.0 -0700
+++ Makefile.new2012-06-13 12:12:26.0 -0700
@@ -15,8 +15,6 @@
tcl84:${PORTSDIR}/lang/tcl84 \
tk84:${PORTSDIR}/x11-toolkits/tk84
-BROKEN=does not build
-
MASTERDIR= ${.CURDIR}/../vtk
WRAP= Python
@@ -41,8 +39,9 @@
-DZLIB_INCLUDE_DIR:PATH=/usr/include \
-DJPEG_LIBRARY:PATH=${LOCALBASE}/lib/libjpeg.so \
-DJPEG_INCLUDE_DIR:PATH=${LOCALBASE}/include \
- -DPNG_LIBRARY:PATH=${LOCALBASE}/lib/libpng.so \
+ -DPNG_LIBRARY:PATH=${LOCALBASE}/lib/libpng15.so \
-DPNG_INCLUDE_DIR:PATH=${LOCALBASE}/include/libpng15 \
+ -DPNG_PNG_INCLUDE_DIR:PATH=${LOCALBASE}/include/libpng15 \
-DTIFF_LIBRARY:PATH=${LOCALBASE}/lib/libtiff.so \
-DTIFF_INCLUDE_DIR:PATH=${LOCALBASE}/include \
-DTCL_INCLUDE_PATH:PATH=${TCL_INCLUDE_DIR} \
--
Steve
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [PATCH] Fix vtk-python port
On Wed, Jun 13, 2012 at 10:16:21PM +0100, Chris Rees wrote:
> On 13 June 2012 21:51, Chris Rees wrote:
> > On 13 June 2012 21:05, Steve Kargl
> > wrote:
> >>
> >> --- Makefile 2012-06-09 02:25:25.0 -0700
> >> +++ Makefile.new 2012-06-13 12:12:26.0 -0700
> >> @@ -15,8 +15,6 @@
> >> tcl84:${PORTSDIR}/lang/tcl84 \
> >> tk84:${PORTSDIR}/x11-toolkits/tk84
> >>
> >> -BROKEN= does not build
> >> -
> >> MASTERDIR= ${.CURDIR}/../vtk
> >>
> >> WRAP= Python
> >> @@ -41,8 +39,9 @@
> >> -DZLIB_INCLUDE_DIR:PATH=/usr/include \
> >> -DJPEG_LIBRARY:PATH=${LOCALBASE}/lib/libjpeg.so \
> >> -DJPEG_INCLUDE_DIR:PATH=${LOCALBASE}/include \
> >> - -DPNG_LIBRARY:PATH=${LOCALBASE}/lib/libpng.so \
> >> + -DPNG_LIBRARY:PATH=${LOCALBASE}/lib/libpng15.so \
> >> -DPNG_INCLUDE_DIR:PATH=${LOCALBASE}/include/libpng15 \
> >> + -DPNG_PNG_INCLUDE_DIR:PATH=${LOCALBASE}/include/libpng15 \
> >> -DTIFF_LIBRARY:PATH=${LOCALBASE}/lib/libtiff.so \
> >> -DTIFF_INCLUDE_DIR:PATH=${LOCALBASE}/include \
> >> -DTCL_INCLUDE_PATH:PATH=${TCL_INCLUDE_DIR} \
> >
> > I'm testing this now.
> >
> > Please send a PR next time to avoid multiple people checking the patch.
>
> Committed. Thanks!
>
> Chris
You're welcome.
--
Steve
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: HELP: New Port: devel/pocl: A portable OpenCL library with LLVM backend
On Sat, Sep 08, 2012 at 10:57:49AM +0200, O. Hartmann wrote: > Hello. > I tried to create a "port", see the Makefile attached I created already. > For further informations and your convenience, look at this website: > Please stop cross posting to freebsd-current when you have some issue that clearly belongs in free-ports. -- Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: lang/icon: Port does not respect "USE_GCC=4.6+ override and stops building duet to "BROKEN" flag
On Tue, Sep 25, 2012 at 02:42:23PM +0200, O. Hartmann wrote: > If someone overrides the default system compiler which is in my case > CLANG 3.2 (on FreeBSD 10.0-CURRENT #1 r240885M: Mon Sep 24 12:30:44 > CEST 2012 amd64), the if-statement does always take place and prevents > lang/icon to be build: > Please, do not cross-post freebsd-port issues to freebsd-current. -- Steve ___ freebsd-ports@freebsd.org mailing list http://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&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: 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&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"
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 > 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&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 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"
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: 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"
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"
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: 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"
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: 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: 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: 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"
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: 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"
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 "$@&q
Re: devel/jsoncpp and staging?
On Wed, Dec 19, 2018 at 02:35:00AM +0900, Yasuhiro KIMURA wrote: > From: Steve Kargl > Subject: Re: devel/jsoncpp and staging? > Date: Tue, 18 Dec 2018 08:21:46 -0800 > > >> 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 experienced same problem with 13.0-CURRENT r341690. See thread > starting with following message for more detail. > > https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072355.html > > Regards. > Yasuhiro KIMURA, 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. -- 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 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"
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: 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"
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 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 11:34:28AM -0200, Lucas Nali de Magalhães wrote: > > > > My lumina builds indirectly build qt5-qui and have been having > > no problems (targeting amd64, aarch64, armv7, and powerpc64). > > (My powerpc64 context is not normally gcc 4.2.1 based.) > > > > [...] > > So it looks like it's 32bit specific; maybe i386 only. > Yes, likely. I'll note that valgrind hass been broken for a long time, now that I think about it was built with -march=native. -- 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 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 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 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 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"
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))
^
/usr/ports/graphics/drm-legacy-kmod/work/drm-legacy-50ea058/src/dev/drm2/ttm
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"
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 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: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 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: 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: 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: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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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: "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"
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: 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"
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: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 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 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 fo
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: 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: 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: 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: 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 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: 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: 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"
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"
