error: undefined symbol: OPENSSL_cpuid_setup
While playing with compiling www/chromium, I'm seeing make stop with /usr/bin/ld.lld: error: undefined symbol: OPENSSL_cpuid_setup This is on a Raspberry Pi 3 running FreeBSD www.zefox.org 12.0-ALPHA7 FreeBSD 12.0-ALPHA7 r338880 GENERIC with ports at 480613 World and kernel build, install and run acceptably, so the system as a whole isn't hugely broken. Can anybody suggest a fix/workaround? Thanks for reading! bob prohaska ___ 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: error: undefined symbol: OPENSSL_cpuid_setup
On Mon, Sep 24, 2018 at 07:26:08PM -0700, bob prohaska wrote: > While playing with compiling www/chromium, I'm seeing make stop with > /usr/bin/ld.lld: error: undefined symbol: OPENSSL_cpuid_setup > > This is on a Raspberry Pi 3 running > FreeBSD www.zefox.org 12.0-ALPHA7 FreeBSD 12.0-ALPHA7 r338880 GENERIC > with ports at > 480613 > > World and kernel build, install and run acceptably, so the system as > a whole isn't hugely broken. Can anybody suggest a fix/workaround? Changed the make command to make -DBATCH DISABLE_VULNERABILITIES=yes DEFAULT_VERSIONS+=ssl=base > make.log but make stopped with the same error: /usr/bin/ld.lld: error: undefined symbol: OPENSSL_cpuid_setup >>> referenced by crypto.c >>> crypto.o:(do_library_init) in archive >>> obj/third_party/boringssl/libboringssl.a c++: error: linker command failed with exit code 1 (use -v to see invocation) It's not clear to me if this is an issue with the port, or the base system. Any advice appreciated! bob prohaska ___ 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: error: undefined symbol: OPENSSL_cpuid_setup
On Wed, Sep 26, 2018 at 09:53:32AM +, Lorenzo Salvadore via freebsd-ports wrote: > > > While playing with compiling www/chromium, I'm seeing make stop with > > > /usr/bin/ld.lld: error: undefined symbol: OPENSSL_cpuid_setup > > > This is on a Raspberry Pi 3 running > > > FreeBSD www.zefox.org 12.0-ALPHA7 FreeBSD 12.0-ALPHA7 r338880 GENERIC > > > with ports at > > > 480613 > > > World and kernel build, install and run acceptably, so the system as > > > a whole isn't hugely broken. Can anybody suggest a fix/workaround? > > > > Changed the make command to > > make -DBATCH DISABLE_VULNERABILITIES=yes DEFAULT_VERSIONS+=ssl=base > > > make.log > > > > but make stopped with the same error: > > /usr/bin/ld.lld: error: undefined symbol: OPENSSL_cpuid_setup > > > > > > > referenced by crypto.c > > > > > crypto.o:(do_library_init) in archive > > > > > obj/third_party/boringssl/libboringssl.a > > > > c++: error: linker command failed with exit code 1 (use -v to see > > invocation) > > > > It's not clear to me if this is an issue with the port, or the base system. > > Any advice appreciated! > > I might be wrong, but I see some similiraties with an issue discussed in > those days > under the subject "error: undefined symbol: main in poudriere jail". It was a > linking problem that appeared only on 12.0-ALPHA7 (or current any anyway, not > on > 11.2-RELEASE). I suggest you take a look into it. > > Here are the links to the most relevant messages (from the week archive, so > they > will not work anymore after the week pass and then you will have to search > them > in an other archive): > https://docs.freebsd.org/cgi/getmsg.cgi?fetch=87161+0+current/freebsd-ports > https://docs.freebsd.org/cgi/getmsg.cgi?fetch=108259+0+current/freebsd-ports > My situation is much simpler than the one described, there's no jail, just a plain "make" in /usr/ports/www/chromium. Hopefully it'll be less complex! Thanks for reading and posting, bob prohaska ___ 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-static: xorgproto-2018.4 conflicts with glproto-1.4.17
In trying to get a usable web browser running on a Raspberry Pi 2 running 11.2-STABLE #3 r339214 I keep running into conflicts between ports trying to put files in the same place. In this particular case, the make command was root@www:/usr/ports/graphics/gdk-pixbuf # make -DBATCH DISABLE_VULNERABILITIES=yes MAKE_JOBS_UNSAFE=yes FORCE_PKG_REGISTER=yes with an overall goal of compiling www/epiphany, or any graphical browser that works. Xfce4 managed to compile and work, but it didn't build a browser. What's the customary way to resolve conflicts of this type? It would be OK to break older ports if necessary; I just want to get a web browser that runs and don't need a desktop environment. TWM is enough for my purposes. Thanks for reading, bob prohaska ___ 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-static: xorgproto-2018.4 conflicts with glproto-1.4.17
On Sun, Oct 07, 2018 at 06:57:15PM +0200, Walter Schwarzenfeld wrote: > /usr/ports/MOVED > > x11/glproto|x11/xorgproto|2018-07-31|merged into x11/xorgproto. > > run > > grep proto /usr/ports/MOVED > > a lot of "*proto-ports" are merged into xorgproto. > That got me past the ports conflict, alas to no avail. Epiphany wants gnome3, gnome3 stopped with editor/meson.build:120:0: ERROR: Invalid version of dependency, need 'glib-2.0' ['>= 2.55.1'] found '2.50.3'. Is there any GUI browser available for 11-stable on the Pi2? Lynx runs, but it's effectively unusable on modern, graphics-formatted websites. Thanks for your help, bob prohaska ___ 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-static: xorgproto-2018.4 conflicts with glproto-1.4.17
On Sun, Oct 07, 2018 at 07:52:48PM +0200, Walter Schwarzenfeld wrote: > Recent version?? of glib20 is 2.56.1. > > Ahh! I knew the latest was 2.56.1 but failed to guess it was called glib20. Tried just about everything but Thank you! bob prohaska ___ 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"
Missing globaladdr implementation for www/webkit2-gtk3
In trying to compile numerous ports on an RPI3 that depend on www/webkit2-gtk3 the process stops with errors along the lines of DerivedSources/JavaScriptCore/LLIntAssembly.h:1349:2: error: Missing globaladdr implementation #error Missing globaladdr implementation Both the system and ports tree are current. The make command is simply make -DBATCH Is there a workaround? Thanks for reading, bob prohaska ___ 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"
Compiling firefox on Raspberry Pi 2
Attempts to compile firefox63 on an RPI2 fail with ===> rust-1.29.2 is only for aarch64 amd64 i386, while you are running armv6 (reason: requires prebuilt bootstrap compiler). *** Error code 1 while compilation of firefox-esr stops with dt_modtext:/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_link.c(856): arm not implemented dtrace: failed to link script /usr/ports/www/firefox-esr/work/firefox-52.8.0esr/js/src/devtools/javascript-trace.d: an error was encountered while processing jsarray.o gmake[5]: *** [/usr/ports/www/firefox-esr/work/firefox-52.8.0esr/config/rules.mk:788: js-dtrace.o] Error 1 gmake[5]: Leaving directory '/usr/ports/www/firefox-esr/work/.build/js/src' gmake[4]: *** [/usr/ports/www/firefox-esr/work/firefox-52.8.0esr/config/recurse.mk:71: js/src/target] Error 2 gmake[4]: Leaving directory '/usr/ports/www/firefox-esr/work/.build' gmake[3]: *** [/usr/ports/www/firefox-esr/work/firefox-52.8.0esr/config/recurse.mk:33: compile] Error 2 gmake[3]: Leaving directory '/usr/ports/www/firefox-esr/work/.build' gmake[2]: *** [/usr/ports/www/firefox-esr/work/firefox-52.8.0esr/config/rules.mk:523: all] Error 2 Can anybody suggest workaround for either problem? Thanks for reading, bob prohaska ___ 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: Compiling firefox on Raspberry Pi 2
On Sat, Oct 20, 2018 at 11:01:15AM +0200, Ronald Klop wrote: > > Not a workaround. Buy you can try to port rust to armv6. Which will > benefit some other ports also. > Rust has tier 2 support for linux/arm, so it might be not so hard to do. > https://forge.rust-lang.org/platform-support.html > You give me too much credit 8-), but I'll look into it. I thought there was an option somewhere to disable rust-dependent features, but I can't find it now. > For Firefox-esr, try to disable DTRACE in the build options of the port. > It says it is not implemented on arm. The default is to build without dtrace: one has to check the box to "Build with DTrace probes" which I've been leaving unchecked. Is there something else I'm missing? Thanks! bob prohaska > > > > > Thanks for reading, > > > > bob prohaska > > > > ___ > > 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" > ___ > 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" ___ 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"
Config dialog seems to crash on RPI#
The configuration dialog box for at least some ports seems to be crashing on an RPI# running recent -current, with a ports tree that was updated in the last day. The crash seems only to suppress changes made, apparently leaving the defaults intact. Make doesn't seem to mind. Right now uname -a reports FreeBSD www.zefox.org 13.0-CURRENT FreeBSD 13.0-CURRENT r339680 GENERIC arm64 An example is security/openssl, but chromium and firefox have behaved similarly: [config dialog didn't copy/paste] Segmentation fault (core dumped) ===> Options unchanged ===> Installing for openssl-1.0.2p_1,1 ===> Checking if openssl already installed ===> Registering installation for openssl-1.0.2p_1,1 Installing openssl-1.0.2p_1,1... I'm wondering if this suggests a more systematic problem on my system. >From time to time clang crashes with a segfault, other times it runs without issue. Thanks for reading, and any ideas. bob prohaska ___ 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: Config dialog seems to crash on RPI#
On Wed, Oct 24, 2018 at 08:15:36PM +0200, Walter Schwarzenfeld wrote: > I cannot say if it helps, but with dialog problems in the past mostly > helps to recompile ports-mgmt/dialog4ports. > Recompiling dialog4ports certainly didn't hurt, afterwards it worked for chromium (chromium didn't compile anyway, as expected). The whole OS is recompiling now. Thanks for posting, bob prohaska ___ 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"
Can't run pkg-static install on rpi3 at r339840
All of a sudden an attempt to run make in /usr/ports/www/chromium reports pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended but running pkg-static install -f pkg reports pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended Updating FreeBSD repository catalogue... pkg-static: Repository FreeBSD load error: access repo file(/var/db/pkg/repo-FreeBSD.sqlite) failed: No such file or directory pkg-static: http://pkg.FreeBSD.org/FreeBSD:13:aarch64/latest/meta.txz: Not Found repository FreeBSD has no meta file, using default settings pkg-static: http://pkg.FreeBSD.org/FreeBSD:13:aarch64/latest/packagesite.txz: Not Found Unable to update repository FreeBSD Error updating repositories! Any suggestions appreciated! Thanks for reading, bob prohaska ___ 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: Can't run pkg-static install on rpi3 at r339840
On Mon, Oct 29, 2018 at 07:35:38PM +, Nathan Owens via freebsd-ports wrote: > Try pkg-static update first > > > Alas, no luck. Same result as before. Running pkg -N reports ld-elf.so.1: /usr/local/lib/libcrypto.so.9: version OPENSSL_1_1_0 required by /usr/local/lib/libpkg.so.4 not defined, running pkg-static -N reports pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended pkg-static: 511 packages installed So maybe this is fallout of the SSL update. It's unclear to me if the "Warning" message can simply be ignored. Make doesn't seem to stop. I'd be grateful for any pointers to a way out of this pickle. Thanks for reading, bob prohaska ___ 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"
Inkscape compiles but crashes on startup
On an RPI3 running 13.0-CURRENT r339983 inkscape compiled without obvious errors but reports (process:35330): Gtk-WARNING **: 17:00:23.081: Locale not supported by C library. Using the fallback 'C' locale. Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at www.inkscape.org with a detailed description of the steps leading to the crash, so we can fix it. (inkscape:35330): Gtk-WARNING **: 17:00:33.357: ChannelsAction: missing action ChannelsAction [much snippage, ending with] (inkscape:35330): Gtk-WARNING **: 17:00:33.510: ConnectorOverlapAction: missing action ConnectorOverlapAction Abort (core dumped) If anybody has a fix or workaround I'd be pleased to try it. Thanks for reading, bob prohaska ___ 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 compiles but crashes on startup
On Sat, Nov 03, 2018 at 01:29:58AM +0100, Walter Schwarzenfeld wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232073 > > The patch should working. > I tried deleting and recompiling devel/libgmm, but simply re-starting inkscape produces the same error. Is it necessary to recompile other things? Thanks for replying! bob prohaska ___ 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 compiles but crashes on startup
On Sat, Nov 03, 2018 at 07:18:52AM +0100, Walter Schwarzenfeld wrote: > Wait, fix of the primal cause of it is committed right now. > > https://svnweb.freebsd.org/ports?view=revision&revision=483878 > Alas, no luck. Updating the ports tree and recompiling inkscape got rid of the locale error, but inkscape still crashes with an otherwise similar error stream from Gtk. Thanks for reading, bob prohaska ___ 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 compiles but crashes on startup
On Sun, Nov 04, 2018 at 10:47:22AM +0100, T??l Coosemans wrote: > On Sat, 3 Nov 2018 22:31:34 -0700 bob prohaska wrote: > > On Sat, Nov 03, 2018 at 07:18:52AM +0100, Walter Schwarzenfeld wrote: > >> Wait, fix of the primal cause of it is committed right now. > >> > >> https://svnweb.freebsd.org/ports?view=revision&revision=483878 > > > > Alas, no luck. Updating the ports tree and recompiling inkscape got > > rid of the locale error, but inkscape still crashes with an otherwise > > similar error stream from Gtk. > > You have to rebuild devel/glib20. That did the trick, thank you! bob prohaska ___ 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"
ninja error building webkit2-gtk3 on rpi3
Ports are at 484411, system is at 133. Attempts to compile webkit2-gtk3 stops with -c DerivedSources/JavaScriptCore/unified-sources/UnifiedSource86.cpp ninja: build stopped: subcommand failed. ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/www/webkit2-gtk3 I can't find a more detailed statement of what went wrong anywhere in the make output. Thanks for reading, any suggestions appreciated. bob prohaska ___ 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: ninja error building webkit2-gtk3 on rpi3
On Thu, Nov 08, 2018 at 01:23:20PM +0100, Ronald Klop wrote: > On Thu, 08 Nov 2018 02:18:57 +0100, bob prohaska > wrote: > > > Ports are at 484411, system is at 133. Attempts to compile > > webkit2-gtk3 > > stops with > > > > > > -c DerivedSources/JavaScriptCore/unified-sources/UnifiedSource86.cpp > > ninja: build stopped: subcommand failed. > > ===> Compilation failed unexpectedly. > > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure > > to > > the maintainer. > > > Do this part of the message. Before building: > > export MAKE_JOBS_UNSAFE=yes > > That will give a more clear error. > For some reason the export command isn't found (I'm using whatever shell su gives me for root) but digging through the make log found an old error that's been around for some time: In file included from /usr/ports/www/webkit2-gtk3/work/webkitgtk-2.20.5/Source/JavaScriptCore/l lint/LowLevelInterpreter.cpp:559: DerivedSources/JavaScriptCore/LLIntAssembly.h:795:2: error: Missing globaladdr implementation #error Missing globaladdr implementation If somebody is aware of a fix please clue me in. Thanks for reading, bob prohaska ___ 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: ninja error building webkit2-gtk3 on rpi3
On Fri, Nov 09, 2018 at 04:57:23PM +0100, Kurt Jaeger wrote: > Hi! > > > > > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the > > > > failure > > > > to > > > > the maintainer. > > > > > > Do this part of the message. Before building: > > > > > > export MAKE_JOBS_UNSAFE=yes > > > > > > That will give a more clear error. > > > > > For some reason the export command isn't found (I'm using whatever shell su > > gives me for root) > > Which is csh, so: > > setenv MAKE_JOBS_UNSAFE yes > > would work. > > > DerivedSources/JavaScriptCore/LLIntAssembly.h:795:2: error: Missing > > globaladdr implementation > > #error Missing globaladdr implementation > > > > If somebody is aware of a fix please clue me in. > > Walter pointed me to a PR which had a fix. I added the fix to the > port, please test if it helps. > Yes, webkit2-gtk3 now compiles successfully on RPI3. Thank you! bob prohaska ___ 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"
More troubles building www/epiphany
Now that webkit2-gtk3 compiles correctly make in www/epiphany stops on what looks like a version of the openssl upgrade problem: ld-elf.so.1: /usr/local/lib/libcrypto.so.9: version OPENSSL_1_1_0 required by /usr/local/lib/libarchive.so.13 not defined Command '['/usr/ports/devel/appstream-glib/work/appstream-glib-0.7.8/_build/tmp-introspect4zt426i5/AppStreamGlib-1.0', '--introspect-dump=/usr/ports/devel/appstream-glib/work/appstream-glib-0.7.8/_build/tmp-introspect4zt426i5/functions.txt,/usr/ports/devel/appstream-glib/work/appstream-glib-0.7.8/_build/tmp-introspect4zt426i5/dump.xml']' returned non-zero exit status 1. ninja: build stopped: subcommand failed. *** Error code 1 Stop. make[4]: stopped in /usr/ports/devel/appstream-glib *** Error code 1 Stop. make[3]: stopped in /usr/ports/devel/appstream-glib *** Error code 1 Stop. make[2]: stopped in /usr/ports/x11-fonts/cantarell-fonts *** Error code 1 Stop. make[1]: stopped in /usr/ports/x11/gnome-desktop *** Error code 1 Stop. make: stopped in /usr/ports/www/epiphany At this point /etc/make.conf contains the single line DEFAULT_VERSIONS+=ssl=openssl in response to a warning from earlier make attempts. /etc/src.conf is not present. What's the best way to proceed? I started to compile security/openssl111 but was greeted by an immediate conflict warning with no obvious resolution. The system is at FreeBSD 13.0-CURRENT r340325 GENERIC arm64 Thanks for reading, bob prohaska ___ 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: More troubles building www/epiphany
On Sun, Nov 11, 2018 at 12:16:47AM +0100, Dimitry Andric wrote: > > After r339270 (the upgrade of base OpenSSL to 1.1.1) and r339709 > (bumping of OpenSSL shared libraries to version 111), you must delete > all your ports, and rebuild them from scratch. > > Yes, it sucks. :) > Ok, at least I know now. Thanks! bob prohaska ___ 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: More troubles building www/epiphany
On Sat, Nov 10, 2018 at 03:35:59PM -0800, bob prohaska wrote: > On Sun, Nov 11, 2018 at 12:16:47AM +0100, Dimitry Andric wrote: > > > > After r339270 (the upgrade of base OpenSSL to 1.1.1) and r339709 > > (bumping of OpenSSL shared libraries to version 111), you must delete > > all your ports, and rebuild them from scratch. > > > > Yes, it sucks. :) > > > > Ok, at least I know now. > For lack of a better idea, I tried running "make deinstall" in /usr/ports/ to clean house. It appeared to at least partly work, but now trying to make -DBATCH in www/webkit2-gtk3 the make process stops while building cmake: [ 5%] Built target cmsys [ 7%] Built target cmsys_c [ 7%] Built target cmcompress [ 74%] Built target CMakeLib [ 75%] Built target CMakeServerLib [ 88%] Built target CTestLib [ 88%] Built target ctest [ 94%] Built target CPackLib [ 95%] Built target cpack [ 96%] Built target cmake [ 99%] Built target ccmake [100%] sphinx-build man: see Utilities/Sphinx/build-man.log Traceback (most recent call last): File "/usr/local/bin/sphinx-build", line 6, in from pkg_resources import load_entry_point File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3112, in @_call_aside File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3096, in _call_aside f(*args, **kwargs) File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3125, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 578, in _build_master ws.require(__requires__) File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 895, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 781, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'typing' distribution was not found and is required by Sphinx *** Error code 1 Stop. make[4]: stopped in /usr/ports/devel/cmake/work/cmake-3.12.4 *** Error code 1 Stop. make[3]: stopped in /usr/ports/devel/cmake/work/cmake-3.12.4 *** Error code 1 Stop. make[2]: stopped in /usr/ports/devel/cmake/work/cmake-3.12.4 *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/cmake *** Error code 1 Stop. make: stopped in /usr/ports/devel/cmake The file Utilities/Sphinx/build-man.log is present, but empty. This is a new problem, apparently precipitated by attempting to delete old ports. For the moment I'm trying to manually compile python27, to see if it helps. If there's a better thing to try please let me know. Thanks for reading, bob prohaska ___ 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: More troubles building www/epiphany
On Sun, Nov 11, 2018 at 06:55:12PM +0100, Walter Schwarzenfeld wrote: > Compile CMake with DOCS=off. > For some reason it wasn't necessary, cmake compiled after a couple cycles of cleaning and reinstalling. Now webkit2-gtk3 is getting stuck compiling libsoup: checking for glib-networking (glib TLS implementation)... no configure: error: libsoup requires glib-networking for TLS support. If you are building a package, you can pass --disable-tls-check to allow building libsoup anyway (since glib-networking is not actually required at compile time), but you should be sure to add a runtime dependency on it. ===> Script "configure" failed unexpectedly. Please report the problem to gn...@freebsd.org [maintainer] and attach the "/usr/ports/devel/libsoup/work/libsoup-2.62.2/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. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 Stop. make[2]: stopped in /usr/ports/devel/libsoup *** Error code 1 The really strange thing is that glib-networking compiled and installed without visible errors, so it's not clear why the test failed. Any ideas appreciated, including a way to cleanly remove all ports and start over! This is on an RPI3, so there are, far as I know, no precompiled packages available. Thanks for reading, bob prohaska ___ 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"
libsoup can't find glib-networking on rpi3
For some reason attempts to compile libsoup stop on a failure to find glib-networking, despite the latter being installed and up-to-date. I've experimented with simply commenting out the BUILD_DEPENDS and RUN_DEPENDS lines in the Makefile, make fails in the same way, which is slightly surprising. I expected at least a different error. Ports are at 484876, sources are at 340358. The goal here is to compile www/epiphany, which depends on webkit2-gtk3, which dpends on libsoup, which requires glib-networking. If there's another way to go about compiling a graphical browser that works please advise me. Thanks for reading, bob prohaska ___ 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"
Resolving ports conflicts for ImageMagick6
In trying to bring inkscape up to date on r340487 the process is getting stuck with ===> Registering installation for ImageMagick6-6.9.10.14,1 as automatic Installing ImageMagick6-6.9.10.14,1... pkg-static: ImageMagick6-6.9.10.14,1 conflicts with ImageMagick-6.9.9.28_2,1 (installs files into the same place). Problematic file: /usr/local/bin/Magick++-config *** Error code 70 The problem seems to have its origin in the rename of the imagemagick port mentioned in /usr/ports/UPDATING for November 10th. How does one work past a problem like this? Thanks for reading, bob prohaska ___ 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: Resolving ports conflicts for ImageMagick6
On Sun, Nov 18, 2018 at 10:32:15AM -0800, David Wolfskill wrote: > On Sun, Nov 18, 2018 at 09:43:39AM -0800, bob prohaska wrote: > > In trying to bring inkscape up to date on r340487 the process > > is getting stuck with > > > > ===> Registering installation for ImageMagick6-6.9.10.14,1 as automatic > > Installing ImageMagick6-6.9.10.14,1... > > pkg-static: ImageMagick6-6.9.10.14,1 conflicts with > > ImageMagick-6.9.9.28_2,1 (installs files into the same place). Problematic > > file: /usr/local/bin/Magick++-config > > *** Error code 70 > > I did so via "pkg delete -f graphics/ImageMagick". > That worked, Thank you! bob prohaska ___ 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: Resolving ports conflicts for ImageMagick6
On Sun, Nov 18, 2018 at 07:49:41PM +0100, Christoph Moench-Tegeder wrote: > ## bob prohaska (f...@www.zefox.net): > > > Installing ImageMagick6-6.9.10.14,1... > > pkg-static: ImageMagick6-6.9.10.14,1 conflicts with > > ImageMagick-6.9.9.28_2,1 (installs files into the same place). Problematic > > file: /usr/local/bin/Magick++-config > > *** Error code 70 > > Make sure your installed packages are up-to-date with your ports tree. > Using old packages with a new ports tree (or vice versa) results in... this. I neglected to mention this in on an RPI3, so packages aren't available. It never crossed my mind that pkg could be used to remove a port compiled from source. I tried "make deinstall", but by then the old ImageMagick port had morphed into ImageMagick6 and deinstall didn't work. bob prohaska ___ 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"
Inkscape package troubles, "libicuuc.so.62" not found
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? Thanks for reading, bob prohaska ___ 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 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. bob prohaska ___ 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 09:53:28AM -0800, David Wolfskill wrote: > I strongly suspect that you are encountering "complications" because of > a lack of consistency with respect to installed ports/packages on the > system in question. > > That is, "consistency" with respect to the state of the underlying ports > tree(s) that was/were used to build the ports & packages in question. > I broke inkscape by mistakenly deleting an old library required by the old(ish) port of inkscape. Libmap.conf provided an escape in this case. More generally, is there a way to determine what revision of the ports tree will successfully compile/run a given port, if it existed in the past? Thanks for reading, bob prohaska ___ 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"
Can't compile sysutils/u-boot-rpi3 on rpi3
In trying to compile sysutils/u-boot-rpi3 natively the compilation stops with many errors caused by rsa-sign.c /usr/bin/ld: error: undefined symbol: OPENSSL_init_ssl >>> referenced by rsa-sign.c >>> tools/lib/rsa/rsa-sign.o:(rsa_sign) /usr/bin/ld: error: undefined symbol: EVP_MD_CTX_new >>> referenced by rsa-sign.c >>> tools/lib/rsa/rsa-sign.o:(rsa_sign) and so on. The system is at r341083, ports are at 486064. Buildworld and buildkernel both work, so the basics are ok. I'd like to try updating u-boot to see if it fixes Timeout poll on interrupt endpoint messages that seem to interfere with hands-off rebooting. Thanks for reading, bob prohaska ___ 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: Can't compile sysutils/u-boot-rpi3 on rpi3
On Wed, Nov 28, 2018 at 02:38:34PM +0900, KIRIYAMA Kazuhiko wrote: > At Tue, 27 Nov 2018 18:06:59 -0800, > bob prohaska wrote: > > > > In trying to compile sysutils/u-boot-rpi3 natively the compilation > > stops with many errors caused by rsa-sign.c > > > > /usr/bin/ld: error: undefined symbol: OPENSSL_init_ssl > > >>> referenced by rsa-sign.c > > >>> tools/lib/rsa/rsa-sign.o:(rsa_sign) > > > > /usr/bin/ld: error: undefined symbol: EVP_MD_CTX_new > > >>> referenced by rsa-sign.c > > >>> tools/lib/rsa/rsa-sign.o:(rsa_sign) > > > > > > and so on. > > Maybe OpenSSL 1.1 API problems [1]. > The errors listed in the bug report didn't include any of the form "undefined symbol". Not sure how significant the distinction is, but it looks different to a naive eye. > [1] https://wiki.freebsd.org/OpenSSL/1.1.0 > Thanks for reading! bob prohaska ___ 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"
How much memory to compile www/chromium?
How much memory should be required for make -DBATCH in www/chromium? Make issues warnings about disk space required, but I don't recall seeing anything about RAM or swap. The system in question is an RPI3 running r341643. Make reached part [18416/30819], at which point it seems to have stalled. The machine is still (sluggishly) responsive, gstat is reporting dT: 10.050s w: 10.000s L(q) ops/sr/s kBps ms/rw/s kBps ms/wd/s kBps ms/d %busy Name 8588149708 25.7439 20567.7 0 00.0 100.0 mmcsd0 8588149708 25.7439 20567.8 0 00.0 100.0 mmcsd0s2 8588149708 25.7439 20567.8 0 00.0 100.0 mmcsd0s2b That it got stuck on reading, rather than writing, is a little surprising. Swapinfo reports Device 1K-blocks UsedAvail Capacity /dev/mmcsd0s2b4404252 2705928 169832461% If this is expected, is there a way to reduce the number of threads started by make? It's using four now, all in state SWREAD showing WCPU of zero to a few percent. Top is reporting mostly idle, with system and interrupt at less than 10%. There are swap_pager_getswapspace(32): failed messages on the console, so it really is out of memory. Thanks for reading! bob prohaska ___ 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: How much memory to compile www/chromium?
On Wed, Dec 12, 2018 at 07:41:49PM +0100, Christoph Moench-Tegeder wrote: > ## bob prohaska (f...@www.zefox.net): > > > How much memory should be required for > > make -DBATCH > > in www/chromium? > > Quite a lot, multiple GBs. > > > I'm not even sure if your SD card will survive that :) > That's ok, I'm trying to discover what is and isn't practical on a Pi3 > > If this is expected, is there a way to reduce the number of > > threads started by make? > > See bsd.ports.mk: DISABLE_MAKE_JOBS (as in "make -DDISABLE_MAKE_JOBS"). > Thank you, I think that's the information needed. Come to think of it, will the -j option, such as -j2, work in this situation also? Two threads are much better than one 8-) As it happens, the machine isn't stuck. Make still seems to be running, now it's up to [18466/30819], admittedly not making fast progress. I'll let it run for now, just to see what happens. Thanks for your help, bob prohaska ___ 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: How much memory to compile www/chromium?
On Wed, Dec 12, 2018 at 09:25:04PM +0100, Christoph Moench-Tegeder wrote: > ## bob prohaska (f...@www.zefox.net): > > > > See bsd.ports.mk: DISABLE_MAKE_JOBS (as in "make -DDISABLE_MAKE_JOBS"). > > > > > Thank you, I think that's the information needed. Come to think of it, > > will the -j option, such as -j2, work in this situation also? Two threads > > are much better than one 8-) > > If you had looked into bsd.port.mk yourself... right below the docs of > DISABLE_MAKE_JOBS (line 814) is some documentation for MAKE_JOBS_NUMBER > and MAKE_JOBS_NUMBER_LIMIT. -j won't help because there's a lot of Setting MAKE_JOBS_NUMBER_LIMIT=2 seems to have the desired effect. Still, top reports four c++ processes, but only two are running and swap use seldom exceeds 1GB at worst. So far, that's been enough to prevent stalling. Editing /usr/ports/Mk/bsd.port.mk looks like it'll affect all ports; what's the convention for making the change local to www/chromium only? Thanks for your patience! bob prohaska ___ 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: How much memory to compile www/chromium?
On Fri, Dec 14, 2018 at 05:59:21AM +0100, Jan Beich wrote:
>
> MAKE_JOBS_NUMBER_LIMIT is a user variable, so you can either set in
> make.conf or Makefile.local e.g.,
>
> $ cat <<\. >>${__MAKE_CONF:-/etc/make.conf}
> .if ${.CURDIR:M*/www/chromium}
> MAKE_JOBS_NUMBER_LIMIT=2
> .endif
Setting MAKE_JOBS_NUMBER_LIMIT=2 allowed www/chromium to compile successfully
over
several days. The -DBATCH option was used, in hopes it'd fetch the right
options.
Swap usage fluctuated over the course of the build, from a minimum of
around 230MB to over one GB at several points. Past about 500MB the CPU
usage dropped, evidently from I/O limitations to the microSD based swap
partition, which was far too big at 4GB.
One curiousity was a gradual increase in minimum swap usage, from about 230
MB initially to about 280 MB a couple days later. This wasn't a highly
systematic observation, just me looking at a top window from time to time.
When the build finished swap use dropped back to ~20MB, which is the normal
idle state.
The resulting executable turned up in /usr/local/bin/chrome, which was
slightly surprising; the port's name is chromium, after all It seems
to run, but is too slow to play Youtube videos smoothly. For static pages
it seems fine.
The major problem is a complete lack of audio. I'm using an HDMI to DVI cable
and plugging the audio system into the Pi3's headphone jack. Is there some
trick to getting the headphone jack to work?
Thanks for reading, and everyone's help getting chromium to work on the Pi3.
bob prohaska
___
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"
RPI3 sound for www/chromium, was Re: How much memory to compile www/chromium?
On Tue, Dec 18, 2018 at 11:41:44PM +, Jamie Landeg-Jones wrote: > bob prohaska wrote: > > > Setting MAKE_JOBS_NUMBER_LIMIT=2 allowed www/chromium to compile > > successfully over > > several days. The -DBATCH option was used, in hopes it'd fetch the right > > options. > > Use "make config-recursive" before you start. It will present to you upfront > all > the option screens that would appear during the build. > > I've noticed it sometimes misses some, if you add some dependency in one of > the menus. > So to be sure, once it's finished its run, if you've made any option changes, > run > it again, and again and again etc.. until you no longer get menus popping up. > That's a good idea provided one knows beforehand which options to select. I very seldom know which options apply, especially on the first try. After a few failures my guesses sometimes improve In the case of www/chromium it looks like the sound support is wrong, but so far it isn't obvious which sound option is correct. Would anybody hazard a guess as to what sound support works on a Pi3? The clearest hint so far is a report of ALSA lib pcm_oss.c:835:(_snd_pcm_oss_open) Cannot open device /dev/dsp when starting up chrome. Thanks for reading! bob prohaska ___ 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: RPI3 sound for www/chromium, was Re: How much memory to compile www/chromium?
On Wed, Dec 19, 2018 at 05:14:07PM +1100, Brian Scott wrote: > > I believe the problem now is that support for builtin sound on the RPI3 > is still a work in progress (it goes through the HDMI subsystem and I > think it was a 32 vs. 64 bit issue but is a mystery to me beyond that). > I infer that sound is only a distant murmur on the Pi3. 8-) Thanks for the clarification! bob prohaska > ___ 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: How much memory to compile www/chromium?
On Tue, Dec 18, 2018 at 09:49:03AM -0800, bob prohaska wrote: > > Setting MAKE_JOBS_NUMBER_LIMIT=2 allowed www/chromium to compile successfully > over > several days. The -DBATCH option was used, in hopes it'd fetch the right > options. > Just for fun I added a mechanical hard disk with a 4 GB swap partition and re-ran the www/chromium compilation with MAKE_JOBS_NUMBER_LIMIT unset, to see what happens. OOMA was turned off with vm.pageout_oom_seq="2048" in /boot/loader.conf. After ~11 days the process finished. Log files of gstat output and make output are at http://www.zefox.net/~fbsd/rpi3/swaptests/r342204/chromium/mech_sd/ in case anyone's curious. The log files are around 100MB, it seems quickest to download them to look around. Swap use peaked at 3522008 kB. If gstat is to be believed the bottleneck appears to be the mechanical hard disk, which showed near 100% busy when the microSD swap partition was around 15% busy. Apart from a few "indefinite wait..." warnings on the console there was no indication of errors. As a further test, I'ved added two additional USB flash swap devices and am re-running the compilation of www/chromium. The swap layout is quite lopsided, with the USB flash devices having only 2 GB swap partitions on each, contrasting to the 4 GB swap partitions on the microSD card and mechanical disk. The first oddity is that top doesn't seem to see the extra swap space, reporting only 7192M total. Swapinfo does seem to plausibly report swap status as Device 1K-blocks UsedAvail Capacity /dev/mmcsd0s2b440425252228 4352024 1% /dev/da0p1419430450848 4143456 1% /dev/da2p5209715228232 2068920 1% /dev/da1f 209715228060 2069092 1% Total12792860 159368 12633492 1% after running overnight. "indefinite wait..." warnings on the console have returned in abundance with the use of USB flash swap, even though swap usage is still less than 200MB. Thanks for reading, bob prohaska ___ 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: How much memory to compile www/chromium?
On Tue, Jan 01, 2019 at 03:14:26PM -0800, Mark Millard wrote: > > > On 2019-Jan-1, at 10:21, bob prohaska wrote: > > > On Tue, Dec 18, 2018 at 09:49:03AM -0800, bob prohaska wrote: > > > > > > As a further test, I'ved added two additional USB flash swap devices and am > > re-running > > the compilation of www/chromium. The swap layout is quite lopsided, with > > the USB flash > > devices having only 2 GB swap partitions on each, contrasting to the 4 GB > > swap partitions > > on the microSD card and mechanical disk. > > > > The first oddity is that top doesn't seem to see the extra swap space, > > reporting only > > 7192M total. > > If you start top before changing the swap space (swapon or > swapoff), top does not change to match: it does not monitor > the swap space total size over time. But I've no other clue > to the ordering that actually occurred. > In fact I made that mistake so I quit and restarted top. The incorrect swap total number persisted. After a fashion the number makes some sense: The small swap partitions are 2 GB, if the swap is used uniformly the total would be 8 GB. 7192 MB is less wrong than the ~13GB reported by swapinfo. > > You might want to report the types/models of the USB flash devices that > were in used. Also relevant is the past usage pattern and amount of > prior use on the USB flash devices. > > The flash devices are the same Sandisk Extreme "thumb drives" used in earlier swap experiments with buildworld. One is model SDCZ80-064, the other SDCZ800-064. The former is rated USB3.0, the latter USB3.1. They're certainly not new, but neither are they obviously broken (yet). Thanks for reading! bob prohaska ___ 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: How much memory to compile www/chromium?
> > On 2019-Jan-1, at 10:21, bob prohaska wrote: > > > On Tue, Dec 18, 2018 at 09:49:03AM -0800, bob prohaska wrote: > >> > >> Setting MAKE_JOBS_NUMBER_LIMIT=2 allowed www/chromium to compile > >> successfully over > >> several days. The -DBATCH option was used, in hopes it'd fetch the right > >> options. > >> > > > > Just for fun I added a mechanical hard disk with a 4 GB swap partition and > > re-ran > > the www/chromium compilation with MAKE_JOBS_NUMBER_LIMIT unset, to see what > > happens. > > OOMA was turned off with vm.pageout_oom_seq="2048" in /boot/loader.conf. > > > > After ~11 days the process finished. Log files of gstat output and make > > output are at > > http://www.zefox.net/~fbsd/rpi3/swaptests/r342204/chromium/mech_sd/ > > > > As a further test, I'ved added two additional USB flash swap devices and am > > re-running > > the compilation of www/chromium. The swap layout is quite lopsided, with > > the USB flash > > devices having only 2 GB swap partitions on each, contrasting to the 4 GB > > swap partitions > > on the microSD card and mechanical disk. > > The attempt to compile chromium using four USB swap partitions didn't complete, but it might have gotten far enough to be surprising. Swap use peaked around 2.4 GB, while the dual swap partition setup used around 3.5 GB of swap at maximum. The make failure happened near the 17000 counter point, when the controlling ssh connection was dropped. I _think_ that's past the point of maximum swap use, but I'll have to re-try to make sure. The log files are at http://www.zefox.net/~fbsd/rpi3/swaptests/r342204/chromium/flash_mech_sd/ in case anybody is curious. Thanks for reading, bob prohaska ___ 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"
Missing modules in devel/rust-cbindgen
In trying to compile /usr/ports/devel/rust-cbindgen on an rpi3 running -current make fails with errors such as error[E0412]: cannot find type `c_long` in the crate root It's tempting to think this is some sort of configuration error. Can anyone suggest a workaround? There don't seem to be any user-configurable options. Rust itself now builds successfully on the rpi3, I think rust-cbindgen might be the only remaining obstacle to compiling some flavor of firefox. Thanks for reading, and any guidance! bob prohaska ___ 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: Missing modules in devel/rust-cbindgen
On Fri, Feb 22, 2019 at 03:43:14PM +0100, Jan Beich wrote: > bob prohaska writes: > > > In trying to compile /usr/ports/devel/rust-cbindgen on an > > rpi3 running -current make fails with errors such as > > > > error[E0412]: cannot find type `c_long` in the crate root > > > > It's tempting to think this is some sort of configuration > > error. Can anyone suggest a workaround? There don't seem > > to be any user-configurable options. > > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235063 > libc-0.2.49 with the fixes is yet to be released. > > > Rust itself now builds successfully on the rpi3, I think > > rust-cbindgen might be the only remaining obstacle to > > compiling some flavor of firefox. > > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234253 > Need help with upstreaming Skia fix. Also waiting for libc-0.2.49. Ok, not so simple after all. Thanks for letting me know. bob prohaska ___ 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"
Config inconsistency for firefox-esr on rpi2
In playing with www/firefox-esr on an rpi2 at r343555 using ports at 493769 make stops with ===> Configuring for firefox-esr-52.8.0,1 firefox-esr-52.8.0,1: Needs gtk3 with WAYLAND support enabled. *** Error code 1 despite both wayland and gtk3 being selected in the config dialog. I've retried several times, the error persists. Any suggestions? Thanks for reading, bob prohaska ___ 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: Config inconsistency for firefox-esr on rpi2
On Sun, Feb 24, 2019 at 11:12:47PM +0100, Dimitry Andric wrote: > > This actually means that you have to rebuild the *gtk3* port with > WAYLAND enabled. It could be worded a little better, maybe. :) > Indeed, it could be worded much better.8-\ There doesn't seem to be a port named gtk3, but there are quite a few with gtk3 in the name. The most likely candidates seem to be: /usr/ports/www/webkit2-gtk3 /usr/ports/www/webkit-gtk3 /usr/ports/www/vimb-gtk3 /usr/ports/devel/gwenhywfar-gtk3 /usr/ports/x11/keybinder-gtk3 /usr/ports/net/avahi-gtk3 /usr/ports/x11-toolkits/rubygem-gtk3 /usr/ports/x11-toolkits/wxgtk30 /usr/ports/x11-toolkits/gtk30 /usr/ports/x11-toolkits/wxgtk31 /usr/ports/audio/libcanberra-gtk3 My first guess would be /usr/ports/x11-toolkits/gtk30, is that right? Thanks for reading! bob prohaska > -Dimitry > ___ 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: Config inconsistency for firefox-esr on rpi2
On Tue, Feb 26, 2019 at 12:54:23AM +0100, Miroslav Lachman wrote: > > Take a look at a dependencies of firefox-esr > https://www.freshports.org/www/firefox-esr/ > > in build dependencies: > gtk3>=3.14.6 : x11-toolkits/gtk30 > I tried for a while to compile various *gtk3 ports, always getting stuck. Most of the trouble seemed to be missing or failed dependencies. Sometimes going to the home of the failure and running make there resolved the problem for that step, but other difficulties always came out of the woodwork. Eventually I think the process ran aground on an error with gstreamer and I gave up. For the moment /usr/src was updated and world is building; much has changed. Then I'll update /usr/ports and start over. > in library dependencies: > libgtk-x11-2.0.so : x11-toolkits/gtk20 > libgtk-3.so : x11-toolkits/gtk30 > > quite confusing gtk20 vs gtk30... > Would it help if there were a uniform method for naming ports and versions and any resulting binaries? Near as I can tell there isn't; some use 1 digit suffixes, some use 2 digits, some delimit with dots, some delimit with dashes. The variety seems endless 8-) > gtk20 has not option WAYLAND so you need to rebuild gtk30 with option > WAYLAND enabled. I neglected to take notes, but gtk30 wouldn't build with wayland enabled by default. Wayland did build by itself, but that's not the problem. It isn't obvious to me if there's a way for multiple ports with conflicting dependencies to automatically name them so the names don't conflict. Seems like it would have to be done at both the source and binary level. Right now it's sometimes hard to figure out what source directory is needed to create a given binary. Thanks for reading, bob prohaska ___ 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: Config inconsistency for firefox-esr on rpi2
On Tue, Feb 26, 2019 at 12:54:23AM +0100, Miroslav Lachman wrote: > > Take a look at a dependencies of firefox-esr > https://www.freshports.org/www/firefox-esr/ > > in build dependencies: > gtk3>=3.14.6 : x11-toolkits/gtk30 > > in library dependencies: > libgtk-x11-2.0.so : x11-toolkits/gtk20 > libgtk-3.so : x11-toolkits/gtk30 > > quite confusing gtk20 vs gtk30... > > gtk20 has not option WAYLAND so you need to rebuild gtk30 with option > WAYLAND enabled. > For some reason gtk30 stops with root@www:/usr/ports/x11-toolkits/gtk30 # gdkkeys-wayland.c:34:10: fatal error: 'fribidi.h' file not found #include I tried compiling gtk20 in the hopes it might provide the missing file, but it completed successfully and fribidi.h remains absent. Last resort was to remake wayland, but that didn't help, gtk30 still stops with missing fribidi.h Is there a way out of this box? Thanks for reading, bob prohaska ___ 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: Config inconsistency for firefox-esr on rpi2
On Wed, Feb 27, 2019 at 07:42:57PM +0100, Walter Schwarzenfeld wrote: > Install converters/fribidi. > Already present, and reinstalled to see if it helps. No luck. The file is in /usr/local/include/fribidi/fribidi.h so there must be some sort of path issue. Thanks for reading! bob prohaska ___ 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"
unknown type name '__uint128_t'
On an rpi3 with system at r344605, ports at 494124 and
CFLAGS=-O2 in /etc/make.conf, an attempt to compile
www/chromium stopped, reporting
In file included from ../../base/third_party/libevent/event.c:49:
In file included from /usr/include/signal.h:42:
/usr/include/machine/ucontext.h:46:2: error: unknown type name '__uint128_t'
__uint128_t fp_q[32];
^
1 error generated.
followed a few lines later by
In file included from ../../base/third_party/libevent/evdns.c:37:
In file included from /usr/include/sys/types.h:46:
/usr/include/machine/endian.h:89:19: error: invalid operand in inline asm:
'rev16 ${0:w}, ${1:w}'
__asm __volatile("rev16 %w0, %w1\n"
^
/usr/include/machine/endian.h:89:19: error: invalid operand in inline asm:
'rev16 ${0:w}, ${1:w}'
/usr/include/machine/endian.h:89:19: error: unexpected token in operand
:1:8: note: instantiated into assembly here
rev16 ,
^
In file included from ../../base/third_party/libevent/evdns.c:37:
In file included from /usr/include/sys/types.h:46:
/usr/include/machine/endian.h:89:19: error: invalid operand in inline asm:
'rev16 ${0:w}, ${1:w}'
__asm __volatile("rev16 %w0, %w1\n"
^
/usr/include/machine/endian.h:89:19: error: invalid operand in inline asm:
'rev16 ${0:w}, ${1:w}'
Errors continue in the same general vein until make gives up.
A month ago chromium would compile (with clang difficulties) and
even run more or less reasonably, so whatever is wrong happened
in a fairly recent timeframe.
Can anybody suggest a fix or workaround?
Thanks for reading,
bob prohaska
___
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: Missing timestamp implementation on rpi3
On Sun, Mar 03, 2019 at 02:39:58PM -0700, Ian Lepore wrote: > On Sun, 2019-03-03 at 10:54 -0800, bob prohaska wrote: > > > > The error it encountered is: > > > > No TimeStamp implementation on this platform. Build will not > > succeed > > > > Correct the error condition and try again. > > > See if this helps... > > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=201510&action=diff > > -- Ian The patch applied without complaint, but restarting make in www/firefox promptly repeated the error. I'm trying make clean followed by make in www/firefox presently. Does lang/rust and friends need rebuilding? Thanks very much! bob prohaska ___ 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: Missing timestamp implementation on rpi3
On Sun, Mar 03, 2019 at 03:46:39PM -0800, bob prohaska wrote: > On Sun, Mar 03, 2019 at 02:39:58PM -0700, Ian Lepore wrote: > > On Sun, 2019-03-03 at 10:54 -0800, bob prohaska wrote: > > > > > > The error it encountered is: > > > > > > No TimeStamp implementation on this platform. Build will not > > > succeed > > > > > > Correct the error condition and try again. > > > > > > See if this helps... > > > > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=201510&action=diff > > > > -- Ian > > The patch applied without complaint, but restarting make in www/firefox > promptly repeated the error. I'm trying make clean followed by make > in www/firefox presently. Does lang/rust and friends need rebuilding? > After cleaning www/firefox compiled and runs (slowly!). Rust seems to have rebuilt as part of the bycatch. Thank you! bob prohaska ___ 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"
Man pages for wireshark don't happen
Just tried making net/wireshark on raspberry pi 2 11.2/stable. GUI failed in gtk5, but CLI version installed successfully. Where does it put the man pages? man wireshark reports No manual entry for wireshark and the docs I could find seemed to talk about the GUI version. Thanks, bob prohaska ___ 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"
Can't compile www/node on rpi2
Recent attempts to compile www/node using 11-Stable on an rpi2 fail with ../src/node_file.cc:2023:15: error: use of undeclared identifier 'uv_fs_lchown' uv_fs_lchown, *path, uid, gid); ^ ../src/node_file.cc:2029:14: error: use of undeclared identifier 'uv_fs_lchown' uv_fs_lchown, *path, uid, gid); followed by many more errors in the same vein. Sources are at r345414, ports are at 496629, this has been going on for some weeks now. Is there a fix or workaround? Thanks for reading, bob prohaska ___ 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: Can't compile www/node on rpi2
On Mon, Mar 25, 2019 at 10:23:26PM +0100, Bradley T. Hughes wrote:
> Hi Bob!
>
> On 2019-03-23 22:39, bob prohaska wrote:
> > Recent attempts to compile www/node using 11-Stable on an rpi2
> > fail with
> > ../src/node_file.cc:2023:15: error: use of undeclared identifier
> > 'uv_fs_lchown'
> >uv_fs_lchown, *path, uid, gid);
> >^
> > ../src/node_file.cc:2029:14: error: use of undeclared identifier
> > 'uv_fs_lchown'
> > uv_fs_lchown, *path, uid, gid);
> > followed by many more errors in the same vein.
>
> I build www/node on i386, amd64, and arm64 before committing version
Not sure it matters, but this is armv7 on a Pi2, not arm64.
> bumps in the hopes that I can build failures like this. I haven't seen
> this one before, though, but from the error, I have to ask which version
> of devel/libuv you have installed? If you don't have the latest, can yo
> upgrade devel/libuv first and try again?
>
Looks like the existing version of libuv was libuv-1.20.3, now it's
up to libuv-1.27.0 but not still fails to build:
In file included from ../src/node_http2.cc:5:
../src/node_http2.h:707:15: error: unknown type name 'nghttp2_origin_entry';
did you mean
'nghttp2_settings_entry'?
void Origin(nghttp2_origin_entry* ov, size_t count);
^~~~
nghttp2_settings_entry
/usr/local/include/nghttp2/nghttp2.h:1068:3: note: 'nghttp2_settings_entry'
declared here
} nghttp2_settings_entry;
^
In file included from ../src/node_http2.cc:5:
../src/node_http2.h:1238:3: error: unknown type name 'nghttp2_origin_entry';
did you mean
'nghttp2_settings_entry'?
nghttp2_origin_entry* operator*() {
^~~~
nghttp2_settings_entry
/usr/local/include/nghttp2/nghttp2.h:1068:3: note: 'nghttp2_settings_entry'
declared here
} nghttp2_settings_entry;
^
In file included from ../src/node_http2.cc:5:
../src/node_http2.h:1239:29: error: unknown type name 'nghttp2_origin_entry';
did you mean
'nghttp2_settings_entry'?
return reinterpret_cast(*buf_);
^~~~
nghttp2_settings_entry
/usr/local/include/nghttp2/nghttp2.h:1068:3: note: 'nghttp2_settings_entry'
declared here
} nghttp2_settings_entry;
^
../src/node_http2.cc:119:62: error: use of undeclared identifier
'NGHTTP2_ORIGIN'
nghttp2_option_set_builtin_recv_extension_type(options_, NGHTTP2_ORIGIN);
^
../src/node_http2.cc:224:3: error: use of undeclared identifier
'NGHTTP2_SETTINGS_ENABLE_CONNECT_PROTOCOL'; did
you mean 'IDX_SETTINGS_ENABLE_CONNECT_PROTOCOL'?
GRABSETTING(ENABLE_CONNECT_PROTOCOL, "enable connect protocol");
^
../src/node_http2.cc:215:33: note: expanded from macro 'GRABSETTING'
nghttp2_settings_entry {NGHTTP2_SETTINGS_##N, val}; \
^
:7:1: note: expanded from here
NGHTTP2_SETTINGS_ENABLE_CONNECT_PROTOCOL
^
../src/node_http2_state.h:18:5: note: 'IDX_SETTINGS_ENABLE_CONNECT_PROTOCOL'
declared here
IDX_SETTINGS_ENABLE_CONNECT_PROTOCOL,
^
../src/node_http2.cc:280:21: error: use of undeclared identifier
'NGHTTP2_SETTINGS_ENABLE_CONNECT_PROTOCOL'
fn(**session, NGHTTP2_SETTINGS_ENABLE_CONNECT_PROTOCOL);
^
../src/node_http2.cc:426:43: error: unknown type name 'nghttp2_origin_entry';
did you mean
'nghttp2_settings_entry'?
buf_.AllocateSufficientStorage((alignof(nghttp2_origin_entry) - 1) +
^~~~
nghttp2_settings_entry
/usr/local/include/nghttp2/nghttp2.h:1068:3: note: 'nghttp2_settings_entry'
declared here
} nghttp2_settings_entry;
^
../src/node_http2.cc:427:50: error: unknown type name 'nghttp2_origin_entry';
did you mean
'nghttp2_settings_entry'?
count_ * sizeof(nghttp2_origin_entry) +
^~~~
nghttp2_settings_entry
/usr/local/include/nghttp2/nghttp2.h:1068:3: note: 'nghttp2_settings_entry'
declared here
} nghttp2_settings_entry;
^
../src/node_http2.cc:433:23: error: unknown type name 'nghttp2_origin_entry';
did you mean
'nghttp2_settings_entry'?
alignof(nghttp2_origin_entry)));
^~~~
nghttp2_settings_entry
/usr/local/include/nghttp2/nghttp2.h:1068:3: note: 'nghttp2_settings_entry'
declared here
} nghttp2_
Re: Can't compile www/node on rpi2
On Tue, Mar 26, 2019 at 12:22:08PM +0100, Bradley T. Hughes wrote: > > > On 2019-03-26 03:14, bob prohaska wrote: > > On Mon, Mar 25, 2019 at 10:23:26PM +0100, Bradley T. Hughes wrote: > [snip] > > Looks like you need to upgrade www/libnghttp2 as well. :) > > > Thanks for reading, I'd be pleased to try any experiments suggested. > > In general, www/node requires that all dependencies are up-to-date. The > port doesn't explicitly list minimum versions of its dependencies, but I > am beginning to think that it should (this is not the first time I have > seen this kind of problem). > Is there a test, a make target perhaps, that will help? I probably should have recognized nghttp2 as a name implying a dependency, but didn't. > Good luck, let me know if you still have problems after making sure > everything is up-to-date. :) > I'm starting to wonder if it's even possible to reconcile dependencies among ports that require mismatched versions of supporting programs and libraries. At the very least it would seem to require an automatic, consistent naming scheme to avoid conflicts and breakage. At small scale it seems feasible, but the ports tree is no longer small. Thanks for reading, and your help! bob prohaska ___ 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: Can't compile www/node on rpi2
On Tue, Mar 26, 2019 at 08:07:48PM +0100, Bradley T. Hughes wrote: > > > On 2019-03-26 19:07, Jonathan Chen wrote: > > On Wed, 27 Mar 2019 at 00:24, Bradley T. Hughes wrote: > >> On 2019-03-26 03:14, bob prohaska wrote: > >>> On Mon, Mar 25, 2019 at 10:23:26PM +0100, Bradley T. Hughes wrote: > >> > >> Looks like you need to upgrade www/libnghttp2 as well. :) > >> > >>> Thanks for reading, I'd be pleased to try any experiments suggested. > >> > >> In general, www/node requires that all dependencies are up-to-date. The > >> port doesn't explicitly list minimum versions of its dependencies, but I > >> am beginning to think that it should (this is not the first time I have > >> seen this kind of problem). > > > > You shouldn't have to list the minimum version for dependencies. If > > someone is following the tip of the ports tree, it is expected that > > all the port dependencies are up to date when building a port. Not sure I understand this statement. How can one know the port's dependencies until a build (or something equivalent) is attempted? I'd understand the statement better if there were some way to identify and check out "consistent" versions of the ports tree, for a particular port and revision. Is such a thing possible? > All the > > port-management tools in ports-mgmt assume this, and build > > port-dependancies as required. When building ports, it is always best > > to use one of the build-tools (ie: poudriere, synth , portmaster) > > instead of by hand. > I've played a little with portmaster, and it seemed more prone to stopping unintentionally than a simple "make -DBATCH" in the port directory. IIRC, it always stopped on stale but installed dependencies. Perhaps I'm doing somthing dumb, but I couldn't figure out what it was. Could it merely be the fact that I'm using a Raspberry Pi 2 or 3? > I may not have to, no, but since I have had a couple of reports about > build errors due to out-of-date dependencies, I can help out fellow > users by giving them a helpful message instead of a daunting build error. > > Right? :) > Amen! Informative error messages are a huge help. Library names easily associated with the port that made them would be another large help. Some are obvious, but a few have been real headscratchers. Thank you! bob prohaska ___ 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: Can't compile www/node on rpi2
On Wed, Mar 27, 2019 at 07:45:45AM +0100, Stefan Esser wrote: > Am 27.03.19 um 02:46 schrieb bob prohaska: > >> All the > >>> port-management tools in ports-mgmt assume this, and build > >>> port-dependancies as required. When building ports, it is always best > >>> to use one of the build-tools (ie: poudriere, synth , portmaster) > >>> instead of by hand. > >> > > I've played a little with portmaster, and it seemed more prone to stopping > > unintentionally than a simple "make -DBATCH" in the port directory. IIRC, > > it always stopped on stale but installed dependencies. Perhaps I'm doing > > somthing dumb, but I couldn't figure out what it was. Could it merely be > > the fact that I'm using a Raspberry Pi 2 or 3? > > Could you provide me with traces of portmaster runs for cases where it did > not upgrade stale dependencies? > Please describe how to capture a trace and I'll give it a try. Thanks for reading! bob prohaska ___ 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"
RPI3, error: invalid operand in inline asm: 'rev16 ${0:w}, ${1:w}'
In a recent attempt to compile www/chromium on an RPI3 running r345516
compilation stopped with repeated reports of
/usr/include/machine/endian.h:89:19: error: invalid operand in inline asm:
'rev16 ${0:w}, ${1:w}'
Chromium compiled on the same host a couple of months ago, but the
executable failed on a runtime library error. Now attempts to upgrade
stop during compilation. Ports are presently at revision 496949.
Thanks for reading, and any guidance.
bob prohaska
___
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: RPI3, error: invalid operand in inline asm: 'rev16 ${0:w}, ${1:w}'
On Sat, Mar 30, 2019 at 05:50:35PM +, John F Carr wrote:
>
>
> > On Mar 30, 2019, at 11:23 , bob prohaska wrote:
> >
> > In a recent attempt to compile www/chromium on an RPI3 running r345516
> > compilation stopped with repeated reports of
> >
> > /usr/include/machine/endian.h:89:19: error: invalid operand in inline asm:
> > 'rev16 ${0:w}, ${1:w}'
> >
> > Chromium compiled on the same host a couple of months ago, but the
> > executable failed on a runtime library error. Now attempts to upgrade
> > stop during compilation. Ports are presently at revision 496949.
> >
> > Thanks for reading, and any guidance.
> >
> > bob prohaska
>
> The swap function at that line in sys/arm64/include/endian.h doesn't look
> right to me. I think it should read
>
> __asm("rev16 %w0, %w1\n" : "=r" (ret) : "r" (w));
>
> instead of
>
> __asm __volatile("rev16 %w0, %w1\n" : "=&r" (ret), "+r" (v));
>
> Two changes: (1) it doesn't need to be volatile because it has no side
> effects and (2) the constraints and lack of explicit input operand are wrong.
> The other swap functions should have similar changes.
>
Apologies for being obtuse, but is that suggestive of a problem with the
host system, or a problem with the port?
Thanks for reading!
bob prohaska
___
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: RPI3, error: invalid operand in inline asm: 'rev16 ${0:w}, ${1:w}'
On Tue, Apr 02, 2019 at 10:39:42AM +, John F Carr wrote: > > The problem I mentioned is with the system. I filed a bug: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236920 > > If you change the system header /usr/include/machine/endian.h > according to the path in that bug report, does chromium compile? The patch applied without difficulty and I've restarted the make process using portmaster-devel. For some reason make in the ports tree seems to be re-extracting distfiles when it isn't necessary, can that be turned off? I think the behavior is new, sometime in the last few months. In this case it'll impose a considerable time penalty. It would appear to render impossible any patching of ports source files. Thanks for reading, and your help! bob prohaska ___ 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: RPI3, error: invalid operand in inline asm: 'rev16 ${0:w}, ${1:w}'
On Tue, Apr 02, 2019 at 09:17:13AM -0700, bob prohaska wrote: > On Tue, Apr 02, 2019 at 10:39:42AM +, John F Carr wrote: > > > > The problem I mentioned is with the system. I filed a bug: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236920 > > > > If you change the system header /usr/include/machine/endian.h > > according to the path in that bug report, does chromium compile? > > The patch applied without difficulty and I've restarted the make > process using portmaster-devel. > The compile stopped again, seemingly with the same error, unchanged. Oddly, there's also an error immediately before, which has been seen before but I thought has been fixed at some point, In file included from ../../base/third_party/libevent/event.c:49: In file included from /usr/include/signal.h:42: /usr/include/machine/ucontext.h:46:2: error: unknown type name '__uint128_t' __uint128_t fp_q[32]; ^ 1 error generated. The relevant parts of the console output are at http://www.zefox.net/~fbsd/rpi3/portmaster/chromium/r345516/console.txt in case anybody's willing to take a look. Thanks for reading, bob prohaska ___ 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: RPI3, error: invalid operand in inline asm: 'rev16 ${0:w}, ${1:w}'
On Tue, Apr 02, 2019 at 08:31:12PM +, John F Carr wrote: > > > > On Apr 2, 2019, at 14:09 , bob prohaska wrote: > > > > On Tue, Apr 02, 2019 at 09:17:13AM -0700, bob prohaska wrote: > >> On Tue, Apr 02, 2019 at 10:39:42AM +, John F Carr wrote: > >>> > >>> The problem I mentioned is with the system. I filed a bug: > >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236920 > >>> > >>> If you change the system header /usr/include/machine/endian.h > >>> according to the path in that bug report, does chromium compile? > >> > >> The patch applied without difficulty and I've restarted the make > >> process using portmaster-devel. > >> > > > > The compile stopped again, seemingly with the same error, unchanged. > > > > Oddly, there's also an error immediately before, which has been seen > > before but I thought has been fixed at some point, > > > > In file included from ../../base/third_party/libevent/event.c:49: > > In file included from /usr/include/signal.h:42: > > /usr/include/machine/ucontext.h:46:2: error: unknown type name '__uint128_t' > >__uint128_t fp_q[32]; > >^ > > 1 error generated. > > > > The relevant parts of the console output are at > > > > http://www.zefox.net/~fbsd/rpi3/portmaster/chromium/r345516/console.txt > > > > in case anybody's willing to take a look. > > > > Thanks for reading, > > > > bob prohaska > > I looked a little closer and figured out why it's failing. The chromium port > compiles with options "--target=arm-linux-gnueabihf -march=armv7-a". That > means it's using a Linux ABI on 32 bit ARM v7. The byte reverse functions in > machine/endian.h do not work with that target. I think the rev* instructions > don't exist in ARM v7. > > Does chromium come with object files built for ARM7a on Linux, so that target > has to be used? I hope that question is directed to someone else! I can only state that a couple of versions ago chromium compiled and ran on the Pi3. That particular compile session had to be restarted many times to finish. By the time I was able to re-run it, compilation was successful but the executable failed with an error in a shared object library. Since then, roughly early February, chromium hasn't compiled on the Pi3. Prior to early February it compiled with difficulties connected to VM limitations. Thanks for reading! bob prohaska ___ 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"
/bin/sh: java: not found when compiling www/chromium on RPI3
On an RPi3, after updating ports to 497846 and sources to r345516, attempts to compile www/chromium stop with /bin/sh: java: not found when using either make or portmaster. There seems to be neither a java execuable, nor a java port, anywhere on the system. There is a /usr/local/bin/node, which is the closest connection I can identify. Any suggestions appreciated! Thanks for reading, bob prohaska ___ 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: /bin/sh: java: not found when compiling www/chromium on RPI3
On Sat, Apr 06, 2019 at 01:19:42AM +0200, Jan Beich wrote: > bob prohaska writes: > > > On an RPi3, after updating ports to 497846 and sources to r345516, > > attempts to compile www/chromium stop with > > /bin/sh: java: not found > > when using either make or portmaster. > > USE_JAVA check may need to be relaxed but on -CURRENT you'll bump into > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236566 I don't really understand the bug report, but gather it'll be a minute to fix. Thank you! bob prohaska ___ 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"
"libicuuc.so.61" not found, required by "libephymisc.so" on RPi2
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! bob prohaska ___ 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 05:59:20PM +0200, Kurt Jaeger wrote: > Hi! > > > Try this messy workaround: > > cd /usr/local/lib > ls -l libicuuc* > > Then symlink the available libicuuc.so.NN to the requested: > > ln -s libicuuc.so.NN libicuuc.so.61 > That worked, thank you! bob prohaska ___ 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"
Python conflict on RPI2
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 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Python conflict on RPI2
On Fri, Apr 12, 2019 at 06:49:40PM -0700, Steve Kargl wrote: > > pkg info | grep py > py.txt > pkg delete -f py27-setuptools-40.8.0 > install 3.6 > re-install python27 Looks like that's working. I'm still baffled where the py27-setuptools-40.8.0 came from. And, it seems there're a few other py27-related packages that'll have to be deleted manually. Thank you very much! bob prohaska ___ 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 Sat, Apr 13, 2019 at 04:09:13AM +0200, Jan Beich wrote: > bob prohaska writes: > > > 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 > > Reinstall py27-setuptools first. When PYTHON_DEFAULT is changed it > requires rebuilding USE_PYTHON=concurrent (or USES=uniquefiles) > consumers in order to make symlinks point to the new default. Is there any hope of simply replacing python27 with python36? The goal at hand is merely to compile a working version of firefox. Thanks for your help! bob prohaska ___ 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 Sat, Apr 13, 2019 at 02:07:28AM +, Tatsuki Makino wrote: > Steve Kargl wrote on 2019/04/13 10:49: > > > > pkg info | grep py > py.txt > > pkg delete -f py27-setuptools-40.8.0 > > install 3.6 > > re-install python27 > > > > > > py27-cython and py27-sphinx are also cause. > Probably, pkg query -e %\#r\ =\ 0 -g %n py27-\* ports/packages can be > deleted in advance. > Indeed, there's quite a bit of stale material to remove. I tried pkg delete -f py27-\* and it offered to remove many py27-* packages and a few that didn't match by name. Since I can afford to break things on this host I accepted the offer and await the outcome with interest. I'm still rather baffled as to what's going on. One of the first things tried was to deinstall python27, expecting the removal of all traces that might conflict with installing python36. Clearly that didn't happen. Have I got something misconfigured? Or, is this expected behavior for ports? Thanks for writing! bob prohaska ___ 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"
2.32 assertion fail elflink.c:2935 on RPi2
Attempts to build www/firefox on rpi2 fail during compilation of llvm60, with /usr/local/bin/ld: BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935 There don't seem to be any other error messages in the build output. Swap usage peaks at 16%, vm.pageout_oom_seq=2048 . The machine is running FreeBSD www.zefox.com 11.2-STABLE FreeBSD 11.2-STABLE #2 r345473: Sun Mar 24 08:57:56 PDT 2019 b...@www.zefox.com:/usr/obj/usr/src/sys/RPI2 arm with ports at 498696. Thanks for reading and any suggestions. bob prohaska ___ 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: 2.32 assertion fail elflink.c:2935 on RPi2
On Mon, Apr 15, 2019 at 08:09:24AM +0200, Dimitry Andric wrote: > On 15 Apr 2019, at 06:30, bob prohaska wrote: > > /usr/local/bin/ld: BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935 > > > > Likely a BFD ld bug, but see: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068 > Looks like I'm in good company 8-) Thanks for writing bob prohaska ___ 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"
stack protector mode differs in PCH file vs. current file:
In trying (still) to compile www/chromium on an RPI3 running -current with ports at 500082 and system at 346613 portmater is stopping in (I think) openjdk8 with errorerrorerror: : errorstack protector mode differs in PCH file vs. current file: : stack protector mode differs in PCH file vs. current filestack protector mode differs in PCH file vs. current file stack protector mode differs in PCH file vs. current file 1 error generated. 1 error generated. 1 error generated. 1 error generated. gmake[7]: *** [/usr/work/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u212-b04.1/hotspot/make/bsd/makefiles/rules.make:151: mutexLocker.o] Error 1 I tried running make clean in /usr/ports/java/openjdk8 and restarting portmaster, but that didn't seem to help. Thanks for reading, any suggestions appreciated. bob prohaska ___ 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: stack protector mode differs in PCH file vs. current file:
On Sat, Apr 27, 2019 at 03:26:14PM +0200, Jan Beich wrote:
> bob prohaska writes:
>
> > In trying (still) to compile www/chromium on an RPI3 running -current with
> > ports at 500082 and system at 346613 portmater is stopping in (I think)
> > openjdk8 with
> > errorerrorerror: : errorstack protector mode differs in PCH file vs.
> > current file: :
> > stack protector mode differs in PCH file vs. current filestack protector
> > mode differs in PCH file vs. current file
> > stack protector mode differs in PCH file vs. current file
>
> Can't say much without full build log but it maybe a regression from
> https://svnweb.freebsd.org/changeset/ports/499897
>
> Maybe precompiled.hpp.pch is generated with different arguments compared
> to when it's included in source files. Try the following workaround:
>
> --- java/openjdk8/Makefile.orig
> +++ java/openjdk8/Makefile
> @@ -203,14 +203,14 @@ CONFIGURE_ENV+= LIBCXX="-lc++"
> .endif
> .endif
>
> -# GCC is broken with PCH:
> https://lists.freebsd.org/pipermail/svn-src-all/2015-March/101722.html
> .if ${COMPILER_TYPE} == gcc
> CONFIGURE_ARGS+= --with-toolchain-type=gcc
> -.if ${ARCH} == "powerpc64"
> -MAKE_ARGS+= USE_PRECOMPILED_HEADER=1
> -.else
> -MAKE_ARGS+= USE_PRECOMPILED_HEADER=0
> .endif
> +
> +# GCC is broken with PCH:
> https://lists.freebsd.org/pipermail/svn-src-all/2015-March/101722.html
> +# PCH is poorly tested outside of x86
> +.if ${ARCH} != "amd64" || ${COMPILER_TYPE} == gcc
> +MAKE_ARGS+= USE_PRECOMPILED_HEADER=0
> .endif
>
> .if empty(ICONV_LIB)
I'm doing something wrong, patch replies
patch: **** malformed patch at line 22: .if empty(ICONV_LIB)
and exits without doing anything. Come to think of it, shouldn't
.if [anything]
be followed by
.endif
eventually?
Thanks for your help!
bob prohaska
___
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"
ImageMacgick6 seems to conflict with itself
In trying to install ImageMagick6 on an RPI3 compilation finishes, but installation stops with ===> Installing for ImageMagick6-6.9.10.22_1,1 ===> Checking if ImageMagick6 is already installed ===> Registering installation for ImageMagick6-6.9.10.22_1,1 Installing ImageMagick6-6.9.10.22_1,1... pkg-static: ImageMagick6-6.9.10.22_1,1 conflicts with ImageMagick-6.9.9.28_2,1 (installs files into the same place). Problematic file: /usr/local/bin/Magick++-config *** Error code 70 The odd thing is that there is no /usr/local/bin/Magick++-config Using make install FORCE_PKG_REGISTER=yes didn't help, is there something else I should try? Thanks for reading, bob prohaska ___ 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: ImageMacgick6 seems to conflict with itself
On Mon, Apr 29, 2019 at 06:58:35PM -0400, ajtiM via freebsd-ports wrote: > > Maybe make deinstall and then make reinstall > By the time I fell into the trap, the old ImageMagick directory had been renamed to ImageMagick6, which wasn't yet installed, so there was no place to run make deinstall. Using David Wolfskill's pkg command did the trick. Thanks to all for speedy help, bob prohaska ___ 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"
Compiling u-boot-rpi3 on an rpi3
With FreeBSD at r347055 and ports at 500862 attempts to compile sysutils/u-boot-rpi3 stop with a string of errors starting with ld: error: undefined symbol: EVP_MD_CTX_new >>> referenced by mxsimage.c >>> tools/mxsimage.o:(mxsimage_generate) ld: error: undefined symbol: EVP_MD_CTX_free >>> referenced by mxsimage.c >>> tools/mxsimage.o:(mxsimage_generate) ld: error: undefined symbol: EVP_MD_CTX_new >>> referenced by mxsimage.c >>> tools/mxsimage.o:(mxsimage_generate) ld: error: undefined symbol: EVP_CIPHER_CTX_reset >>> referenced by mxsimage.c >>> tools/mxsimage.o:(mxsimage_generate) Is there a fix or workaround? Thanks for reading, bob prohaska ___ 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: Compiling u-boot-rpi3 on an rpi3
On Mon, May 06, 2019 at 06:20:45PM +0200, Mika??l Urankar wrote: > Le lun. 6 mai 2019 ?? 17:19, bob prohaska a ??crit : > > > > On Mon, May 06, 2019 at 03:22:31PM +0200, Mika??l Urankar wrote: > > > > > > It builds fine here on aarch64, do you have security/openssl* installed? > > > > > > > Yes, security/openssl is installed. I didn't use it by default because of > > earlier reports of trouble. The system reminds me that > > Delete it and rebuild u-boot-rpi3 > That certainly helped, make now runs successfully. But, make install didn't update anything in /boot/msdos. There seem to be three copies of u-boot-bin floating around, with identical size. Should I copy one manually to /boot/msdos, and does it matter which one? Thanks for reading and your help! bob prohaska ___ 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"
Configure error for www/node on rpi3 running -current
Attempts to compile www/node on an rpi3 running -current at r349989 with ports at 506782 reports: File "tools/gyp/pylib/gyp/generator/make.py", line 1756, in WriteMakeRule cmddigest = hashlib.sha1(command if command else self.target).hexdigest() AttributeError: 'module' object has no attribute 'sha1' ===> Script "configure" failed unexpectedly. Please report the problem to bhug...@freebsd.org [maintainer] and attach the "/usr/ports/www/node/work/node-v12.6.0/config.log" including the output of the failure of your make command. However, the log file requested doesn't seem to exist. The last successful build of www/node was 12.1, now it's up to 12.6. Thanks for reading, any suggestions appreciated, bob prohaska ___ 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: Configure error for www/node on rpi3 running -current
For reasons unclear to me, recompiling lang/python27 made the problem go away. No upgrade discernible, just a recompile/deinstall/reinstall. Thanks for reading, bob prohaska On Tue, Jul 16, 2019 at 03:41:44PM -0700, bob prohaska wrote: > Attempts to compile www/node on an rpi3 running -current at r349989 with > ports at 506782 reports: > > > File "tools/gyp/pylib/gyp/generator/make.py", line 1756, in WriteMakeRule > cmddigest = hashlib.sha1(command if command else self.target).hexdigest() > AttributeError: 'module' object has no attribute 'sha1' > ===> Script "configure" failed unexpectedly. > Please report the problem to bhug...@freebsd.org [maintainer] and attach the > "/usr/ports/www/node/work/node-v12.6.0/config.log" including the output of > the failure of your make command. > > > However, the log file requested doesn't seem to exist. The last successful > build of www/node was 12.1, now it's up to 12.6. > > Thanks for reading, any suggestions appreciated, > > bob prohaska > > ___ > 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" ___ 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: Clang8 crash on rpi3 at r349989 building openjdk8
On Sun, Sep 01, 2019 at 12:07:15PM +0200, Mika??l Urankar wrote: > > > openjdkd11 is not affected by this bug (and it's the 'mixed' mode > > > version), if you want to try it : > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239246 > > > you'll probably need #237054 > > > > > It's a happy thought, but openjdk11 seems to be amd64 and i386 only. > > I'm on aarch64. > > > > Thanks for writing! > > Support for jdk11/aarch64 has landed in the ports tree. > When the present (likely futile) attempt to compile www/firefox ends I'll give jdk11 a try on aarch64. IIRC, www/chromium tried to compile java/openjdk8 as a dependency. Will having openjdk11 already built (before attempting www/chromium) satisfy the dependency requirement? If more intelligent intervention is needed please tell me how. Many thanks! bob prohaska ___ 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: Clang8 crash on rpi3 at r349989 building openjdk8
On Sun, Sep 01, 2019 at 07:03:18PM +0200, Michael Gmelin wrote: > > Not sure if it helps, but I had to build ports on the rPI3 last year and > ended up cross compiling on amd64. I wrote down what I did back then here: > https://blog.grem.de/sysadmin/FreeBSD-On-rpi3-With-crochet-2018-10-27-18-00.html > Some years ago the older hosts in my collection were retired in favor of RPI, mostly for power saving reasons. I've almost gotten away with it. IME, server and command-line ports that I've tried seem to compile and run without much trouble on ARM. Apache, BIND, sendmail and even Xorg work acceptably. Self-hosting was a hair-puller but seems to work ok recently. Many moons ago www/chromium compiled and ran on aarch64 (PI3) as did firefox. If the project offered a precompiled package for any serviceable browser it'd help, but the need isn't great enough to warrant more hardware. In a pinch, Raspbian offers a decent GUI that mostly works. I hopped on the ARM bandwagon expecting it to move somewhat faster than it has. Evidently the hurdles were bigger than anticipated, but the basics still work quite well. Thanks for posting! bob prohaska ___ 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"
www/chromium error: expected readable system register
An attempt to compile www/chromium on an RPI3 using 13.0-CURRENT #9 r354546 with ports at 517211 reported ../../third_party/boringssl/src/crypto/cpu-aarch64-linux.c:31:18: error: expected readable system register Is there a fix? Thanks for reading, bob prohaska ___ 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"
ERROR: Cannot find cbindgen on RPI2 running 12-stable
In trying to compile firefox on an RPI2 running 12-stable the system reports ERROR: Cannot find cbindgen. Please run `mach bootstrap`, `cargo install cbindgen`, ensure that `cbindgen` is on your PATH, or point at an executable with `CBINDGEN`. Attempts to follow the instructions produce a chain of errors, starting with "permission denied" at running mach. Making mach executable causes a furthter chain of file not found errors. Uname -a reports 12.1-STABLE r355279 RPI2 Ports are at 518859 Thanks for reading, bob prohaska ___ 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"
Chrome can't connect to bus on RPI3 running -current
Www/chromium finally compiled on a Pi3 running -current. The system is presently at (GENERIC) #5 r355919: Sat Dec 21 09:51:45 PST 2019 Chrome can be run (slowly!) across a network and seems to work, but the controlling terminal is littered with bob@www:~ % chrome [1471:1333606144:1221/142239.390187:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [1471:1333606144:1221/142239.751450:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [1471:1333606144:1221/142239.753206:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") [1505:1328579328:1221/142248.078482:ERROR:command_buffer_proxy_impl.cc(124)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer. [1505:1208291328:1221/142251.443394:ERROR:child_process_sandbox_support_impl_linux.cc(81)] FontService unique font name matching request did not receive a response. [1505:1208291328:1221/142251.445950:ERROR:child_process_sandbox_support_impl_linux.cc(81)] FontService unique font name matching request did not receive a response. and that's just opening the home page 8-) /etc/rc.conf contains hald_enable="YES" dbus_enable="YES" Both hald and dbus are visible to pgrep: bob@www:~ % pgrep dbus 1250 1254 1255 955 bob@www:~ % pgrep hald 1127 1131 1100 1101 1103 Are there some other services that need to be turned on? Thanks for reading, bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Runtime problems with www/chromium on RPI3
Chrome finally compiled on an RPI3 and it runs, but reports many errors: [47088:1333610240:0108/212257.960713:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix") and [47125:1208291328:0108/212408.927049:ERROR:child_process_sandbox_support_impl_linux.cc(81)] FontService unique font name matching request did not receive a response. Both hald and dbus are started during boot, and no errors appear on the console, but a check for dbus using ps -aux | grep dbus finds no instance running. Any suggestions appreciated! Thanks for reading, bob prohaska ___ 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"
Conflict on very first port (xorg) on rpi3
An attempt to compile x11/xorg on a new installation of 12.1 on a Pi3B resulted in a conflict: ===> Installing for py37-sphinx18-1.8.5_1,1 ===> Checking if py37-sphinx18 is already installed ===> Registering installation for py37-sphinx18-1.8.5_1,1 as automatic Installing py37-sphinx18-1.8.5_1,1... pkg-static: py37-sphinx18-1.8.5_1,1 conflicts with py37-sphinx-3.0.2,1 (installs files into the same place). Problematic file: /usr/local/bin/sphinx-apidoc-3.7 *** Error code 70 Had this been the umpteenth port compiled, I'd understand somewhat. As the _very_ first port compiled, I'm confounded.. Uname -a reports FreeBSD nemesis.zefox.com 12.1-STABLE FreeBSD 12.1-STABLE r361020 GENERIC arm64 Svnlite info /usr/ports reports: Path: /usr/ports Working Copy Root Path: /usr/ports URL: svn://svn.freebsd.org/ports/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 535263 Node Kind: directory Schedule: normal Last Changed Author: jkim Last Changed Rev: 535263 Last Changed Date: 2020-05-14 20:52:33 -0700 (Thu, 14 May 2020) Thanks for reading, bob prohaska ___ 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: Conflict on very first port (xorg) on rpi3
On Fri, May 15, 2020 at 12:33:10AM -0700, Mark Millard via freebsd-ports wrote: > > Some building and isntalling had to occur prior to the > textproc/py-sphinx18 build attempt, possibly from > prior session(s) of building and installing. > > In this case x11/xorg was the first port attempted in a new ports tree. The only "prior sessions" would have been within the dependencies of x11/xorg. Is that resolvable by poudriere? In compiling poudriere I tried to use the qemu option, since this is on and for a non-x86 architecture. It failed, as arm64 is apparently not supported. Is it required? > textproc/py-sphinx18 is new as of 2020-May-11. > The devel/llvm[16789]0 ports require textproc/py-sphinx18 . > Only about 26 ports require textproc/py-sphinx18 but > I'll not list the others. > > textproc/py-sphinx has been around longer and has > 142 ports that require it. I'll not list them. > > > textproc/py-sphinx18/Makefile lists: > > CONFLICTS_INSTALL= py*-sphinx > > textproc/py-sphinx/Makefile lists: > > CONFLICTS_INSTALL= py*-sphinx18 > > > So, for example, indirectly the devel/llvm[16789]0 > ports conflict with at least 142 other ports because > of the textproc/py-sphinx* difference in requirements. > > > The conflict is real and limits what combinations > of ports you may have installed at the same time. I'll try deinstalling the conflicting port and hope it won't be required later Thanks for writing! bob prohaska ___ 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: Conflict on very first port (xorg) on rpi3
On Fri, May 15, 2020 at 01:49:21PM -0300, Danilo G. Baio wrote: > On Fri, May 15, 2020 at 08:19:22AM -0700, bob prohaska wrote: > > On Fri, May 15, 2020 at 12:33:10AM -0700, Mark Millard via freebsd-ports > > wrote: > > > > > > Some building and isntalling had to occur prior to the > > > textproc/py-sphinx18 build attempt, possibly from > > > prior session(s) of building and installing. > > > > > > > > > > In this case x11/xorg was the first port attempted in a new > > ports tree. The only "prior sessions" would have been within > > the dependencies of x11/xorg. Is that resolvable by poudriere? > > > > > textproc/py-sphinx18 is new as of 2020-May-11. > > > The devel/llvm[16789]0 ports require textproc/py-sphinx18 . > > > Only about 26 ports require textproc/py-sphinx18 but > > > I'll not list the others. > > > > > > textproc/py-sphinx has been around longer and has > > > 142 ports that require it. I'll not list them. > > > > > > > > > textproc/py-sphinx18/Makefile lists: > > > > > > CONFLICTS_INSTALL= py*-sphinx > > > > > > textproc/py-sphinx/Makefile lists: > > > > > > CONFLICTS_INSTALL= py*-sphinx18 > > > > > > > > > So, for example, indirectly the devel/llvm[16789]0 > > > ports conflict with at least 142 other ports because > > > of the textproc/py-sphinx* difference in requirements. > > > > > > > > > The conflict is real and limits what combinations > > > of ports you may have installed at the same time. > > > > I'll try deinstalling the conflicting port and hope > > it won't be required later > > It seems that just devel/llvm80 is pulling sphinx18 when building > x11/xorg. > > Try disabling DOCS option on devel/llvm80 for now. > > I've opened a PR to track this issue: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246487 > Wish I'd known it was only the DOCS option! Too late now, sphinx18 is deinstalled and llvm80 is building. This is probably a dumb question, but is there some way to learn at the outset what conflicts need to be worked around? Something like a "make conflicts" target? Seemingly it could be done by hand, but that promises to be tedious. At best 8-) Thanks for writing! bob prohaska ___ 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: Conflict on very first port (xorg) on rpi3
On Fri, May 15, 2020 at 12:33:02PM -0700, Mark Millard wrote: > [Gack: devel/cmake needs devel/py-sphinx by default > and devel/llvm80 needs both devel/cmake and > devel/py-pshinx18 by default.] > > On 2020-May-15, at 11:59, Mark Millard wrote: > > > > On 2020-May-15, at 11:05, bob prohaska wrote: > > > >> On Fri, May 15, 2020 at 01:49:21PM -0300, Danilo G. Baio wrote: > >>> On Fri, May 15, 2020 at 08:19:22AM -0700, bob prohaska wrote: > >>>> On Fri, May 15, 2020 at 12:33:10AM -0700, Mark Millard via freebsd-ports > >>>> wrote: > >>>>> > >>>>> Some building and isntalling had to occur prior to the > >>>>> textproc/py-sphinx18 build attempt, possibly from > >>>>> prior session(s) of building and installing. > >>>>> > >>>>> > >>>> > >>>> In this case x11/xorg was the first port attempted in a new > >>>> ports tree. The only "prior sessions" would have been within > >>>> the dependencies of x11/xorg. Is that resolvable by poudriere? > >>>> > >>>>> textproc/py-sphinx18 is new as of 2020-May-11. > >>>>> The devel/llvm[16789]0 ports require textproc/py-sphinx18 . > >>>>> Only about 26 ports require textproc/py-sphinx18 but > >>>>> I'll not list the others. > >>>>> > >>>>> textproc/py-sphinx has been around longer and has > >>>>> 142 ports that require it. I'll not list them. > >>>>> > >>>>> > >>>>> textproc/py-sphinx18/Makefile lists: > >>>>> > >>>>> CONFLICTS_INSTALL= py*-sphinx > >>>>> > >>>>> textproc/py-sphinx/Makefile lists: > >>>>> > >>>>> CONFLICTS_INSTALL= py*-sphinx18 > >>>>> > >>>>> > >>>>> So, for example, indirectly the devel/llvm[16789]0 > >>>>> ports conflict with at least 142 other ports because > >>>>> of the textproc/py-sphinx* difference in requirements. > >>>>> > >>>>> > >>>>> The conflict is real and limits what combinations > >>>>> of ports you may have installed at the same time. > >>>> > >>>> I'll try deinstalling the conflicting port and hope > >>>> it won't be required later > >>> > >>> It seems that just devel/llvm80 is pulling sphinx18 when building > >>> x11/xorg. > >>> > >>> Try disabling DOCS option on devel/llvm80 for now. > >>> > >>> I've opened a PR to track this issue: > >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246487 > >>> > >> > >> Wish I'd known it was only the DOCS option! Too late now, > >> sphinx18 is deinstalled and llvm80 is building. > > > > What? llvm80 requires textproc/py-sphinx18 (when > > the options cause such), not textproc/py-sphinx . > > Deleting textproc/py-sphinx18 and building > > devel/llvm80 will try to rebuild/install > > textproc/py-sphinx18 unless the options are > > set to avoid needing textproc/py-sphinx18 . > > > > To build devel/llvm80 it would be > > textproc/py-sphinx that would be deinstalled first > > so that textproc/py-sphinx18 could be built and > > installed during the build. Sorry, I mis-wrote. What you're describing is what I did. > > > > After devel/llvm80 is installed, textproc/py-sphinx18 > > would be uninstalled so that textproc/py-sphinx could > > be built/installed when xorg is re-tried with llvm80 > > already installed. > > I did not trace down other dependencies but now > looking a little (leaving options at defaults): > > devel/cmake needs devel/py-sphinx by default > and devel/llvm80 needs both devel/cmake and > devel/py-pshinx18 by default. (xorg need not > bein involved: just building devel/llvm[16789]0 > has the issue.) > > Thus the sequence for default options may need > to be something like: > > *) Starting without textproc/py-sphinx18 >installed > > A) build textproc/py-sphinx and devel/cmake >and install devel/cmake ( py-sphinx can >be via indirection through devel/cmake ) >(cmake does not have a run-time dependency >on textproc/py-sphinx as far as I can tell.) > > B) uninstall textproc/py-sphinx so that >textproc/py-sphinx18 can be
LLVM target 'amdgpu' not enabled Was: Re: Conflict on very first port (xorg) on rpi3
Deinstalling the conflicting port made considerable progress toward a build of x11/xorg, but now make is stopping with: configure: error: LLVM target 'amdgpu' not enabled in your LLVM build. Required by radv. I've tried turning off Wayland support in graphics/mesa-dri but that didn't help. Since this is on a Raspberry Pi3B, one wouldn't really expect to find an AMD GPU, If there's a workaround please give me a hint.... Thanks for reading, bob prohaska ___ 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: LLVM target 'amdgpu' not enabled Was: Re: Conflict on very first port (xorg) on rpi3
On Sat, May 16, 2020 at 06:08:13PM +0200, Dimitry Andric wrote: > On 16 May 2020, at 17:44, bob prohaska wrote: > > > > Deinstalling the conflicting port made considerable progress toward a build > > of > > x11/xorg, but now make is stopping with: > > > > configure: error: LLVM target 'amdgpu' not enabled in your LLVM build. > > Required by radv. > > > > I've tried turning off Wayland support in graphics/mesa-dri but that didn't > > help. > > > > Since this is on a Raspberry Pi3B, one wouldn't really expect to find an > > AMD GPU, > > > > If there's a workaround please give me a hint > > It seems to be required by the ATI/AMD Radeon drivers, and there is no > option to turn these drivers off, as far as I can see. You could attempt > to edit graphics/mesa-dri/Makefile, and fiddle with the ALL_DRI_DRIVERS, > ALL_GALLIUM_DRIVERS and ALL_VULKAN_DRIVERS lines. But this is going to > be very fragile, the best solution is really to rebuild the llvm port > with AMDGPU support. > > -Dimitry > Is it known what driver the Pi3B will use? That would at least tell me what to keep, though I appreciate it might not be enough for internal consistency. Quite a few failed attempts will be faster than rebuilding llvm80 Thanks for writing! bob prohaska ___ 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"
More xorg mischief on Rpi3B, failed to open /dev/io
Enabling amdgpu in llvm80 solved the problem of compiling xorg on a Pi3b, but now that it's built and installed it still fails to run. Running X -configure as root produces X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 12.1-STABLE arm64 Current Operating System: FreeBSD nemesis.zefox.com 12.1-STABLE FreeBSD 12.1-STABLE r361020 GENERIC arm64 Build Date: 17 May 2020 04:22:05PM Current version of pixman: 0.40.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon May 18 08:52:43 2020 List of video drivers: scfb modesetting scfb trace: probe start No devices to configure. Configuration failed. (EE) Server terminated with error (2). Closing log file. The log file looks happy until [302404.406] (WW) xf86EnableIO: Failed to open /dev/io for extended I/O [302404.406] (WW) Falling back to old probe method for scfb [302404.406] scfb trace: probe start [302404.406] (WW) Falling back to old probe method for modesetting [302404.406] No devices to configure. Configuration failed. [302404.407] (EE) Server terminated with error (2). Closing log file. There is indeed no /dev/io, and I can't find any references to it. There's a thread at https://forums.freebsd.org/threads/no-devices-to-configure-configuration-failed.18348/ reporting a smilar failure, but traces the problem to having kern_securelevel="1", while mine is -1 (evidently the default). Thanks for reading, any hints appreciated... bob prohaska ___ 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: Missing /dev/io on rpi3 running 12-stable
On Wed, May 20, 2020 at 07:09:11PM +0200, Mika??l Urankar wrote: > Le mer. 20 mai 2020 ?? 18:46, bob prohaska a ??crit : > > > > Is there supposed to be a /dev/io by default in FreeBSD on a Pi3? > > Attempts to start X under 12.1-STABLE r361271 GENERIC fail with > > a report of "failed to open /dev/io". There is indeed no /dev/io, > > but there's also no /dev/io on a pi2 running 12-stable. > > > > Nor does there seem to be a kernel module with matching name > > > > Thanks for reading! > > > > bob prohaska > > I haven't looked closely but it seems the error is in > x11-servers/xorg-server/files/configure.ac, AC_DEFINE(USE_DEV_IO) > Alas, the remedy does not suggest itself, at least not to me Can somebody offer a hint? Thanks for writing! bob prohaska ___ 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: Missing /dev/io on rpi3 running 12-stable
On Wed, May 20, 2020 at 08:56:31PM +0200, Mika??l Urankar wrote: > Le mer. 20 mai 2020 ?? 20:16, bob prohaska a ??crit : > > > > On Wed, May 20, 2020 at 07:09:11PM +0200, Mika??l Urankar wrote: > > > Le mer. 20 mai 2020 ?? 18:46, bob prohaska a ??crit : > > > > > > > > Is there supposed to be a /dev/io by default in FreeBSD on a Pi3? > > > > Attempts to start X under 12.1-STABLE r361271 GENERIC fail with > > > > a report of "failed to open /dev/io". There is indeed no /dev/io, > > > > but there's also no /dev/io on a pi2 running 12-stable. > > > > > > > > Nor does there seem to be a kernel module with matching name > > > > > > > > Thanks for reading! > > > > > > > > bob prohaska > > > > > > I haven't looked closely but it seems the error is in > > > x11-servers/xorg-server/files/configure.ac, AC_DEFINE(USE_DEV_IO) > > > > > > > Alas, the remedy does not suggest itself, at least not to me > > > > Can somebody offer a hint? > > edit files/patch-configure, locate USE_DEV_IO and remove the whole hunk. > then make clean; make deinstall install > Looks like it's not quite that simple. I took the "hunk" to be the preceding line starting with @@ to the next line starting with @@. Make patch finished with no errors, following a fresh make clean, but the build stopped with ld: error: undefined symbol: xf86EnableIO >>> referenced by sdksyms.c >>> sdksyms.o:(xorg_symbols) >>> referenced by xf86Configure.c >>> xf86Configure.o:(DoConfigure) in archive >>> common/.libs/libcommon.a >>> referenced by xf86Events.c >>> xf86Events.o:(xf86VTEnter) in archive common/.libs/libcommon.a >>> referenced by xf86Init.c >>> xf86Init.o:(InitOutput) in archive common/.libs/libcommon.a >>> referenced by xf86Init.c >>> xf86Init.o:(InitOutput) in archive common/.libs/libcommon.a ld: error: undefined symbol: xf86DisableIO >>> referenced by sdksyms.c >>> sdksyms.o:(xorg_symbols) >>> referenced by xf86Events.c >>> xf86Events.o:(xf86VTLeave) in archive common/.libs/libcommon.a ld: error: undefined symbol: xf86OSInitVidMem >>> referenced by vidmem.c >>> vidmem.o:(xf86InitVidMem) in archive >>> os-support/.libs/libxorgos.a cc: error: linker command failed with exit code 1 (use -v to see invocation) gmake[6]: *** [Makefile:814: Xorg] Error 1 Not sure what to try next Thanks for reading! bob prohaska ___ 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: Missing /dev/io on rpi3 running 12-stable
On Wed, May 20, 2020 at 11:01:44AM -0600, Ian Lepore wrote: > On Wed, 2020-05-20 at 09:46 -0700, bob prohaska wrote: > > Is there supposed to be a /dev/io by default in FreeBSD on a Pi3? > > Attempts to start X under 12.1-STABLE r361271 GENERIC fail with > > a report of "failed to open /dev/io". There is indeed no /dev/io, > > but there's also no /dev/io on a pi2 running 12-stable. > > > > Nor does there seem to be a kernel module with matching name > > > > Thanks for reading! > > > > > > /dev/io is an x86 thing, doesn't apply to arm at all. It allows > userland processes with sufficient privs to execute x86 in/out > instructions for talking to old-school ISA bus devices such as > keyboards. Which list is the appropriate forum, -ports, -arm or something else? If there is a better problem description I'll use it. ISTR xorg compiling and running without a hitch on -current previously, ~ a year ago. Thanks for writing, bob prohaska ps, any progress on vc4? ___ 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"
'asm/hwcap.h' file not found building chromium on Pi3
Made another attempt to compile www/chromium on a Pi3B, this time using a mechanical hard disk for all storage (and boot). It stopped with ../../third_party/zlib/cpu_features.c:32:10: fatal error: 'asm/hwcap.h' file not found #include ^ 1 error generated. Ports are at Revision: 537041, uname -a reports 12.1-STABLE r361429 GENERIC arm64. All make commands used -DBATCH. Thanks for reading, any hints appreciated... bob prohaska ___ 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: 'asm/hwcap.h' file not found building chromium on Pi3
On Sun, May 31, 2020 at 09:05:36PM -0700, Mark Millard via freebsd-ports wrote: > > > On 2020-May-31, at 19:22, bob prohaska wrote: > > > Made another attempt to compile www/chromium on a Pi3B, this time using > > a mechanical hard disk for all storage (and boot). It stopped with > > > > ../../third_party/zlib/cpu_features.c:32:10: fatal error: 'asm/hwcap.h' > > file not found > > #include > > ^ > > 1 error generated. > > > > Ports are at Revision: 537041, uname -a reports 12.1-STABLE r361429 > > GENERIC arm64. All make commands used -DBATCH. > > > chromium does not seem to support FreeBSD of itself > so it seems the problem would be considered to be > in the port instead. > The ports were updated to 537591, which seems to have updated www/chromium to chromium-83.0.4103.61, but the error persists. Thanks for reading, bob prohaska ___ 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: 'asm/hwcap.h' file not found building chromium on Pi3
On Thu, Jun 04, 2020 at 05:15:39PM +0200, Christoph Moench-Tegeder wrote: > ## bob prohaska (f...@www.zefox.net): > > > The ports were updated to 537591, which seems to have updated > > www/chromium to chromium-83.0.4103.61, but the error persists. > > asm/hwcap.h does not exist on FreeBSD. That somewhat modified > zlib code tries to include asm/hwcap.h as it believes it's building > on/for Linux on ARM (that #include is guarded by #ifdef ARMV8_OS_LINUX). > Even on Linux, asm/hwcap.h only exists on arm, riscv and some other > platforms, but notably not on anything x86-related. > As to "modified": the whole cpu_features.c is not part of the original > zlib distribution. So, I guess you're in for a deep dive... > I've opened a bug, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246982 FWIW, www/chromium compiled successfully (and even ran, fitfully) about a year ago on the Pi3B. Thanks for replying, bob prohaska ___ 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"
