"fatal error: ac_nonexistent.h: No such file or directory" is the expected result
I have shown: fatal error: ac_nonexistent.h: No such file or directory This is correct, configure is making sure an non-existing include does correctly stop the compilation. Taken from: https://unix.stackexchange.com/questions/360506/what-is-ac-nonexistent-h
Re: mig/build/lexxer.c:1825: undefined reference to `yywrap'
https://stackoverflow.com/questions/1811125/undefined-reference-to-yywrap suggests %option noyywrap in the scanner specification Adding it to ../lexxer.l: It worked! Even the QEMU machine started correctly with the generated gnumach.gz !
Re: mig/build/lexxer.c:1825: undefined reference to `yywrap'
Le mar., 09 févr. 2021 12:47:49 -0500 Samuel Thibault écrit > Paul Dufresne, le mar. 09 févr. 2021 12:29:11 -0500, a ecrit: > It's not looking for bash. It's bash which is looking for "no". See the > configure log, it told you that it didn't find mig. > > Samuel > > I am trying to redo mig. Did (mix of your README and web documentation): TARGET_CPPFLAGS=-I"$GNU"/include ../configure --host=i686-gnu CC=i686-linux-gnu-gcc-10 LD=i686-linux-gnu-ld --prefix="$GNU" Got: paul@jacko:~/mymach/mig/build$ LANG=C make all install Making all in tests make[1]: Entering directory '/home/paul/mymach/mig/build/tests' Making all in good make[2]: Entering directory '/home/paul/mymach/mig/build/tests/good' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/paul/mymach/mig/build/tests/good' Making all in generate-only make[2]: Entering directory '/home/paul/mymach/mig/build/tests/generate-only' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/paul/mymach/mig/build/tests/generate-only' Making all in bad make[2]: Entering directory '/home/paul/mymach/mig/build/tests/bad' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/paul/mymach/mig/build/tests/bad' make[2]: Entering directory '/home/paul/mymach/mig/build/tests' make[2]: Nothing to be done for 'all-am'. make[2]: Leaving directory '/home/paul/mymach/mig/build/tests' make[1]: Leaving directory '/home/paul/mymach/mig/build/tests' make[1]: Entering directory '/home/paul/mymach/mig/build' i686-linux-gnu-gcc-10 -g -O2 -o migcom error.o global.o header.o lexxer.o migcom.o parser.o routine.o server.o statement.o string.o type.o user.o utils.o vprint.o /usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld: lexxer.o: in function `yylex': /home/paul/mymach/mig/build/lexxer.c:1825: undefined reference to `yywrap' collect2: error: ld returned 1 exit status make[1]: *** [Makefile:503: migcom] Error 1 make[1]: Leaving directory '/home/paul/mymach/mig/build' make: *** [Makefile:594: all-recursive] Error 1 paul@jacko:~/mymach/mig/build$ Also, on the build of mach... the configure config.log said: conftest.c:9:10: fatal error: ac_nonexistent.h: No such file or directory 9 | #include | ^~ compilation terminated. configure:5187: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "GNU Mach" | #define PACKAGE_TARNAME "gnumach" | #define PACKAGE_VERSION "1.8" | #define PACKAGE_STRING "GNU Mach 1.8" | #define PACKAGE_BUGREPORT "bug-hurd@gnu.org" | #define PACKAGE_URL "" | /* end confdefs.h. */ | #include configure:5212: result: i686-linux-gnu-gcc-10 -E configure:5232: i686-linux-gnu-gcc-10 -E conftest.c configure:5232: $? = 0 configure:5246: i686-linux-gnu-gcc-10 -E conftest.c conftest.c:9:10: fatal error: ac_nonexistent.h: No such file or directory 9 | #include ... config.status:1539: cd . && sed -e '/# am--include-marker/d' Makefile | make -f - am--depfile s # Ugly bootstrap hack to get to-be-generated files created # Try to guess what file this dependency file is from... # Ugly bootstrap hack to get to-be-generated files created # Try to guess what file this dependency file is from... # Ugly bootstrap hack to get to-be-generated files created # Try to guess what file this dependency file is from... # Ugly bootstrap hack to get to-be-generated files created ... configure:11807: creating ./config.status configure:13149: Applied a patch to work around a deficiency in Automake. See `configure.ac' for details. ... paul@jacko:~/mymach/gnumach/build$ cat config.status.rej --- config.status 2009-10-26 23:57:14.0 +0100 +++ config.status.new 2009-10-27 00:04:26.0 +0100 @@ -1553,7 +1553,14 @@ s/.*/./; q'` as_dir=$dirpart/$fdir; as_fn_mkdir_p # echo "creating $dirpart/$file" - echo '# dummy' > "$dirpart/$file" + # Try to guess what file this dependency file is from... + f=$srcdir/`dirname "$fdir"`/`basename "$file" .Po | sed s/lib[^-]\*-//` + for f in "$f"*; do +case $f in + *.c | *.S) echo "$f"': $(filter-out $(DIST_SOURCES),$(SOURCES))';; + *) echo '# dummy';; +esac + done > "$dirpart/$file" done done } paul@jacko:~/mymach/gnumach/build$
Re: [PATCH] Add multiboot2 header
> > Actually, I'm trying from the hard disk. I can boot from the cdrom and > have a working console if I choose "Legacy BIOS" in the bios > options. But I couldn't install Debian GNU/Linux this way, if I recall > correctly, so now I'm trying to keep uefi. > You probably already have addressed this, so you can ignore this. UEFI support for MBR partitions is quite confusing. Shouldn't the disk have a GPT partition, not an MBR partition, to boot in UEFI without BIOS legacy mode (Compatibility Support Module)? Doesn't Secure Boot need to be turned off in the firmware too? I think Debian is using shim for Secure Boot to work (as the root of trust). Also, doesn't the EFI System Partition(FAT32) need both the grub-efi file (\EFI\debian\grubia*.efi) and bootloader file (\EFI\boot\boot*.efi)*?--there other options for not having a boot file which are probably being used. https://wiki.debian.org/UEFI https://wiki.debian.org/SecureBoot https://uefi.org/specifications/ >
Re: Almost working pci-arbiter with rumpdisk
Damien Zammit, le mar. 09 févr. 2021 21:42:29 +1100, a ecrit: > However, I'm still getting very stuck because I don't seem to have a > "bootstrap" port for fsys_startup() in netfs for pci startup. > Where would the bootstrap port come from to do the arbiter netfs_startup -> > fsys_startup? > As the arbiter netfs IS the bootstrap filesystem, bootstrap is NULL, or am I > confused? It is NULL, yes. > Do I need to implement some kind of netfs_S_fsys_* ? Very probably, yes: I updated http://darnassus.sceen.net/~hurd-web/hurd/bootstrap/ which was saying TODO: we want diskfs_startup_diskfs to also call task_get_bootstrap_port to call fsys_startup on its real bootstrap port once diskfs_start_bootstrap is finished, for bootstrap translators before the root filesystem to know when the root filesystem is ready, and register themselves as translators in the root filesystem, register for shutdown notification, etc. and now says diskfs_start_bootstrap is complete, we are back to diskfs_startup_diskfs, which checks whether ext2fs was given a bootstrap port, i.e. a translator was started before ext2fs. If so, it calls diskfs_call_fsys_startup which creates a new control port and passes it do a call to fsys_startup on the bootstrap port, so the translator that was started before ext2fs gets access to the ext2fs filesystem. That translator however does not return any real port, since we are not exposing the ext2fs filesystem in that translator's filesystem, but rather the converse. That translator will wait for an fsys_init call to complete its own initialization and set itself as an active translator within the ext2fs filesystem. that was for the rumpdisk->ext2fs case, but we'll need the same for the pci-arbiter->rumpdisk case as well, i.e. make trivfs_S_fsys_startup call fsys_startup on its own bootstrap port (thus pci-arbiter), so pci-arbiter gets the control port of the ext2fs FS. Ditto for rumpdisk's fsys_init, that should call fsys_init on its bootstrap port, so that pci-arbiter can eventually configure its own proc, auth, crdir, cwdir, and set itself as active translator in the root filesystem. Samuel
Re: Re : apt-get build-dep gnumach did not install mig
Paul Dufresne, le mar. 09 févr. 2021 12:29:11 -0500, a ecrit: > I think I figure out part of what the problem was. > As I had used: > https://www.gnu.org/software/hurd/microkernel/mach/gnumach/building.html > which use: > $ CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' > ../configure --prefix= --host=i686-unknown-linux-gnu ? I updated the page, perhaps you need to refresh the page. > then: > $ make DESTDIR=~/gnu install-data > I believe there it installed 64 bit headers in ~/gnu... frankly did not look > to them to know. The headers do not depend on the bitness. See the commands used: mkdir, install-sh only, so they only copy the files from the git, that's all. > /bin/bash: no: command not found > make: *** [Makefile:9382: vm/memory_object_user.user.h] Error 127 > paul@jacko:~/mymach/gnumach/build$ > > paul@jacko:~/mymach/gnumach/build$ whereis bash > bash: /usr/bin/bash /etc/bash.bashrc /usr/share/man/man1/bash.1.gz It's not looking for bash. It's bash which is looking for "no". See the configure log, it told you that it didn't find mig. Samuel
Re: wireless setup / tools for intel wireless
Riccardo Mottola, le mar. 09 févr. 2021 18:14:21 +0100, a ecrit: > Samuel Thibault wrote: > > dpkg -L wireless-tools-gnumach > > /usr/sbin/iwconfig > > it does > > > > But remember to use "su -", not only "su", to get your PATH to contain > > /usr/sbin. > > Indeed! or access it directly. However, none is detected: > > lo no wireless extensions. > > /dev/eth no wireless extensions. > > I guess it is not supported and/or I am missing firmware. I checked here: > https://wiki.debian.org/ipw2200 > > 2915ABG is apparently the newer 2200 which needs firmware.: > https://packages.debian.org/sid/firmware-ipw2x00 > > "non-free" is not available for the HURD: does it make any sense to try > install it? I don't think there is support for loading a firmware. Samuel
Re: Re : apt-get build-dep gnumach did not install mig
I think I figure out part of what the problem was. As I had used: https://www.gnu.org/software/hurd/microkernel/mach/gnumach/building.html which use: $ CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' ../configure --prefix= --host=i686-unknown-linux-gnu then: $ make DESTDIR=~/gnu install-data I believe there it installed 64 bit headers in ~/gnu... frankly did not look to them to know. But: http://darnassus.sceen.net/~hurd-web/microkernel/mach/gnumach/building/ which use: $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU" --host=i686-unknown-linux-gnu then I believee: $ make DESTDIR=~/gnu install-data will install the 32 bit headers files. I am a bit ignoring your "new" README file in git for now... to test if that will fix the problem. But I have new one: paul@jacko:~/mymach/gnumach/build$ LANG=C make gnumach.gz rm -f vm/memory_object_user.user.defs.c cp -p ../vm/memory_object_user.cli vm/memory_object_user.user.defs.c rm -f vm/memory_object_default.user.defs.c cp -p ../vm/memory_object_default.cli vm/memory_object_default.user.defs.c rm -f device/device_reply.user.defs.c cp -p ../device/device_reply.cli device/device_reply.user.defs.c rm -f device/memory_object_reply.user.defs.c cp -p ../device/memory_object_reply.cli device/memory_object_reply.user.defs.c rm -f kern/task_notify.user.defs.c cp -p ../kern/task_notify.cli kern/task_notify.user.defs.c rm -f device/device.server.defs.c cp -p ../device/device.srv device/device.server.defs.c rm -f device/device_pager.server.defs.c cp -p ../device/device_pager.srv device/device_pager.server.defs.c rm -f ipc/mach_port.server.defs.c cp -p ../ipc/mach_port.srv ipc/mach_port.server.defs.c rm -f kern/mach.server.defs.c cp -p ../kern/mach.srv kern/mach.server.defs.c rm -f kern/mach4.server.defs.c cp -p ../kern/mach4.srv kern/mach4.server.defs.c rm -f kern/gnumach.server.defs.c cp -p ../kern/gnumach.srv kern/gnumach.server.defs.c rm -f kern/experimental.server.defs.c cp -p ../kern/experimental.srv kern/experimental.server.defs.c rm -f kern/mach_debug.server.defs.c cp -p ../kern/mach_debug.srv kern/mach_debug.server.defs.c rm -f kern/mach_host.server.defs.c cp -p ../kern/mach_host.srv kern/mach_host.server.defs.c rm -f ipc/notify.none.defs.c cp -p ../ipc/notify.defs ipc/notify.none.defs.c rm -f kern/exc.none.defs.c cp -p ../kern/exc.defs kern/exc.none.defs.c rm -f i386/i386/mach_i386.server.defs.c cp -p ../i386/i386/mach_i386.srv i386/i386/mach_i386.server.defs.c cd . && /bin/bash ./config.status version.c config.status: creating version.c i686-linux-gnu-gcc-10 -DHAVE_CONFIG_H -I. -I.. -ffreestanding -nostdinc -imacros config.h -Ii386 -I. -I../i386 -I../i386/include/mach/sa -I../include -E -fno-builtin-log -Wall -fgnu89-inline -fno-strict-aliasing -fno-stack-protector -no-pie -fno-pic -mno-3dnow -mno-mmx -mno-sse -mno-sse2 -g -O2 -MT vm/lib_dep_tr_for_defs_a-memory_object_user.user.defs.o -MD -MP -MF vm/.deps/lib_dep_tr_for_defs_a-memory_object_user.user.defs.Tpo -c -o vm/lib_dep_tr_for_defs_a-memory_object_user.user.defs.o `test -f 'vm/memory_object_user.user.defs.c' || echo '../'`vm/memory_object_user.user.defs.c mv -f vm/.deps/lib_dep_tr_for_defs_a-memory_object_user.user.defs.Tpo vm/.deps/lib_dep_tr_for_defs_a-memory_object_user.user.defs.Po no -n -cc cat - /dev/null \ -user vm/memory_object_user.user.c -header vm/memory_object_user.user.h \ -list vm/memory_object_user.user.msgids \ < vm/lib_dep_tr_for_defs_a-memory_object_user.user.defs.o /bin/bash: no: command not found make: *** [Makefile:9382: vm/memory_object_user.user.h] Error 127 paul@jacko:~/mymach/gnumach/build$ paul@jacko:~/mymach/gnumach/build$ whereis bash bash: /usr/bin/bash /etc/bash.bashrc /usr/share/man/man1/bash.1.gz paul@jacko:~/mymach/gnumach/build$ I may create a symlink /bin/bash on /usr/bin/bash I find it weird it does that.
Re: wireless setup / tools for intel wireless
Hi, Samuel Thibault wrote: dpkg -L wireless-tools-gnumach /usr/sbin/iwconfig it does But remember to use "su -", not only "su", to get your PATH to contain /usr/sbin. Indeed! or access it directly. However, none is detected: lo no wireless extensions. /dev/eth no wireless extensions. I guess it is not supported and/or I am missing firmware. I checked here: https://wiki.debian.org/ipw2200 2915ABG is apparently the newer 2200 which needs firmware.: https://packages.debian.org/sid/firmware-ipw2x00 "non-free" is not available for the HURD: does it make any sense to try install it? I remember that some years ago firmware loading was impossible. What apt-sources would suited in case? Riccardo
Re: Re : apt-get build-dep gnumach did not install mig
Paul Dufresne, le mar. 09 févr. 2021 05:34:56 -0500, a ecrit:
> Le mar., 09 févr. 2021 03:54:27 -0500 Samuel Thibault
> écrit
>
> > Paul Dufresne, le mar. 09 févr. 2021 00:06:37 -0500, a ecrit:
> > > But
> > > # apt-get build-dep gnumach
> > > did not install mig package.
> >
> > Didn't it install mig-for-host and mig-i686-something?
>
> Yes it did.
Then that's what you should use, it provides some /usr/bin/mig-something
that you can tell configure to use with MIG=, just like CC= and LD=
> But as I was trying to reproduce what I was doing on a non-Debian system,
> rather than do:
> dpkg-buildpackage -us -uc -b -rfakeroot
>
> I did: {On Debian Hurd}
> autoreconf --install
> mkdir build
> cd build
> $ GNU=~/gnu
> $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU"
> that then complains it could not find mig.
Yes, because the debian package passes explictly --build= and --host=,
and thus configure finds mig-i686-gnu, so the packaging only has to
build-depend on the mig-i686-gnu on Debian Hurd.
> So I installed mig package and complained here mig was not installed by
> apt-get build-dep gnumach.
Then the problem is in the documentation that told that apt-get
build-dep was enough. Where was it?
> ...
> I was not really aware of mig-for-host and mig-i686-something...
> which are for when you are on Debian Linux?
They are for the debian builds in general, be they cross builds or
non-cross builds.
If somebody could go through these documentations and update them that'd
be very useful.
Samuel
Re: My newly compiled Mach hang on start ext2fs:
Paul Dufresne, le mar. 09 févr. 2021 05:42:42 -0500, a ecrit: > Le mar., 09 févr. 2021 03:54:54 -0500 Samuel Thibault > écrit > > > Paul Dufresne, le lun. 08 févr. 2021 21:08:10 -0500, a ecrit: > > > Last time, after compiling my new gnumach.gz on Ubuntu, I did not tried > it. > > > > > > I tested it on my QEMU environment (Gnu Hurd from this morning)... > > > > > > and it stop on: > > > start ext2fs: > > > with cursor flashsing after. > > > > Had you used a 32bit build of MIG? > > > > Samuel > > > Of course not, as I build on Ubuntu 64 bits, I used a 64 bit build of mig: > paul@jacko:~/mymach/gnumach/gnumach/build$ file ~/gnu/libexec/migcom > /home/paul/gnu/libexec/migcom: ELF 64-bit LSB shared object, x86-64, version > 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, > BuildID[sha1]=533d6a41a9e7f9e2e419ff168084a4f5d02ed284, for GNU/Linux 3.2.0, > with debug_info, not stripped > paul@jacko:~/mymach/gnumach/gnumach/build$ > > that was build from instructions at: > https://www.gnu.org/software/hurd/microkernel/mach/mig/gnu_mig/building.html > ... not: > http://darnassus.sceen.net/~hurd-web/microkernel/mach/mig/gnu_mig/building/ > that seems identical to me at first glance. I have now updated them to mention that it has to be a 32bit build. Samuel
Re: PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko
Paul Sonnenschein wrote: For this specific issue, you should be able to use the patch available at the following Debian bug report for NSPR: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970659 (Alternatively, one might replace the #if with #ifdef PTHREAD_ADAPTIVE_INITIALIZER_NP as recommended at [0]). There also used to be failing tests in NSPR, but some (not all) of them were related to sem_open, which nowadays should be supported by the HURD. the suggestion in the bug report works perfectly. I will commit into arcticfox. However, compilation dies later on: 8:36.88 from /home/multix/code/Arctic-Fox/obj-i686-unknown-gnu0.9/dom/cellbroadcast/Unified_cpp_dom_cellbroadcast0.cpp:2: 8:36.88 /home/multix/code/Arctic-Fox/ipc/chromium/src/build/build_config.h:36:2: error: #error Please add support for your platform in build/build_config.h 8:36.88 36 | #error Please add support for your platform in build/build_config.h 8:36.88 | ^ 8:36.90 In file included from ../../dist/include/nsISupportsUtils.h:14, Allowing a modern Gecko-based Browser to compile on the HURD should be a significant amount of work, up to and including porting Rust (allowing Rust to cross-compile code using only libcore and liballoc for the HURD should be relatively easy, the hard part would be porting the complete standard library and allowing the Rust compiler to run on the Hurd, I am a bit unsure whether porting liblibc is still necessary for porting libstd, if it still is, that would be an additional, significant amount of work). The advantage is ArcticFox is that it is still rust-less, which makes it much more portable and easier to compile Of course "not so modern", but still usable and without the nasty distribution limitations of PaleMoon. For this reason it has users in niches beyond the mainstrem Linux/x86-64: it still works well on i386 and I recently restored MIPS-le and Raspberry3 support. So trying the HURD is just logical and potentially a decent candidate too. If you HURD people already had some patches accepted upstream in Firefox though, I need to backport them. Riccardo
Re: [PATCH] Add multiboot2 header
Andrea G. Monaco, le mar. 09 févr. 2021 16:34:21 +0100, a ecrit: > could you please try it too Samuel? To be frank, ATM I don't have time to spend on diverse things. I already have a hard time managing to do my daily work without hitting my sleep time. Samuel
Re: [PATCH] Add multiboot2 header
> Maybe before grub-mkconfig: GRUB_GFXPAYLOAD_LINUX > or using e to edit boot configuration and add: > https://www.gnu.org/software/grub/manual/grub/grub.html#gfxpayload > they say it set the video mode in which Linux is started... but > maybe it would apply to Mach too. I tried, but it doesn't. In fact, Linux doesn't use multiboot, but its own boot protocol; that's why there are grub commands and variables made especially for it. > before grub-mkconfig... I realize that if you are using a CD > image... you don't easily control the grub-mkconfig part. Actually, I'm trying from the hard disk. I can boot from the cdrom and have a working console if I choose "Legacy BIOS" in the bios options. But I couldn't install Debian GNU/Linux this way, if I recall correctly, so now I'm trying to keep uefi. > It is when I try to use the module command after the multiboot2 > command that I get "error: you need to load the kernel first.". I got the same response after trying "module /hurd/ext2fs.static". Maybe "multiboot2" loading fails silently. Alas, grub2 messages are very terse or absent, even when I "set debug=all". Maybe mb2 implementation is incomplete. I also tried removing all tags - mb2 info, flags and module alignment, but not the closing tag - but nothing changed, could you please try it too Samuel? Warmly, Andrea Monaco
Re: PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko
Samuel Thibault, le mar. 09 févr. 2021 13:44:00 +0100, a ecrit: > Riccardo Mottola, le mar. 09 févr. 2021 13:04:54 +0100, a ecrit: > > Richard Braun wrote: > > > The _NP suffix means non-posix, and is generally used for system-specific > > > features. The use of "adaptive" mutexes is probably just an optimization, > > > so it should be completely safe to just comment it out on systems where > > > the macro doesn't exist (assuming it's a macro). > > > > thank you, it must be optional: > > > > #if (defined(LINUX) && (__GLIBC__ > 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ > > >= 2)) || \ > > (defined(FREEBSD) && __FreeBSD_version > 700055) > > rv = pthread_mutexattr_settype(&_pt_mattr, PTHREAD_MUTEX_ADAPTIVE_NP); > > PR_ASSERT(0 == rv); > > #endif > > > > does HURD define LINUX? > > No. But Linux not define LINUX either, so I rather guess that the > application misdetected the GNU system as a GNU/Linux system and > erroneously defined LINUX. (Indeed the parentheses are wrong)
Re: PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko
Riccardo Mottola, le mar. 09 févr. 2021 13:04:54 +0100, a ecrit: > Richard Braun wrote: > > The _NP suffix means non-posix, and is generally used for system-specific > > features. The use of "adaptive" mutexes is probably just an optimization, > > so it should be completely safe to just comment it out on systems where > > the macro doesn't exist (assuming it's a macro). > > thank you, it must be optional: > > #if (defined(LINUX) && (__GLIBC__ > 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ > >= 2)) || \ > (defined(FREEBSD) && __FreeBSD_version > 700055) > rv = pthread_mutexattr_settype(&_pt_mattr, PTHREAD_MUTEX_ADAPTIVE_NP); > PR_ASSERT(0 == rv); > #endif > > does HURD define LINUX? No. But Linux not define LINUX either, so I rather guess that the application misdetected the GNU system as a GNU/Linux system and erroneously defined LINUX. Samuel
Re: wireless setup / tools for intel wireless
Riccardo Mottola, le mar. 09 févr. 2021 12:43:03 +0100, a ecrit: > I have installed wireless-tools-gnumach, but shouldn't I have "iwconfig" > with it? can't find it. dpkg -L wireless-tools-gnumach /usr/sbin/iwconfig it does But remember to use "su -", not only "su", to get your PATH to contain /usr/sbin. Samuel
Re: PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko
Hi, Am Dienstag, dem 09.02.2021 um 13:04 +0100 schrieb Riccardo Mottola:> > [...] > thank you, it must be optional: > > #if (defined(LINUX) && (__GLIBC__ > 2) || (__GLIBC__ == 2 && > __GLIBC_MINOR__ >= 2)) || \ > (defined(FREEBSD) && __FreeBSD_version > 700055) > rv = pthread_mutexattr_settype(&_pt_mattr, > PTHREAD_MUTEX_ADAPTIVE_NP); > PR_ASSERT(0 == rv); > #endif > > does HURD define LINUX? somehow counterintuitive, I'd expect only > GNU, but not LINUX: would help in these situations Hi, look at the patch in the bug report I mentioned: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=970659;filename=nspr_pr_src_pthreads_ptsynch.c.diff;msg=5 The error lies at the parentheses and (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 2) is true for the HURD. Paul > Riccardo > > signature.asc Description: This is a digitally signed message part
Re: PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko
Hi Richardm, Richard Braun wrote: The _NP suffix means non-posix, and is generally used for system-specific features. The use of "adaptive" mutexes is probably just an optimization, so it should be completely safe to just comment it out on systems where the macro doesn't exist (assuming it's a macro). thank you, it must be optional: #if (defined(LINUX) && (__GLIBC__ > 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 2)) || \ (defined(FREEBSD) && __FreeBSD_version > 700055) rv = pthread_mutexattr_settype(&_pt_mattr, PTHREAD_MUTEX_ADAPTIVE_NP); PR_ASSERT(0 == rv); #endif does HURD define LINUX? somehow counterintuitive, I'd expect only GNU, but not LINUX: would help in these situations Riccardo
Re: PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko
Hi, TL;DR: A patch for the mentioned issue exists, but porting Gecko is a lot of work Am Dienstag, dem 09.02.2021 um 10:36 +0100 schrieb Riccardo Mottola: > how is compilation of Gecko related browsers going on? I am trying to > compile ArcticFox and I get this: > 3:43.44 > /home/multix/code/Arctic-Fox/nsprpub/pr/src/pthreads/ptsynch.c:60:48: > error: ‘PTHREAD_MUTEX_ADAPTIVE_NP’ undeclared (first use in this > function); did you mean ‘PTHREAD_MUTEX_FAST_NP’? > 3:43.44 60 | rv = pthread_mutexattr_settype(&_pt_mattr, > PTHREAD_MUTEX_ADAPTIVE_NP); > 3:43.44 | ^ > 3:43.44 | PTHREAD_MUTEX_FAST_NP > > > The code is almost unchanged with current gecko, so I wonder if > there were any workarounds attempted and/or upliftable patches for > that. For this specific issue, you should be able to use the patch available at the following Debian bug report for NSPR: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970659 (Alternatively, one might replace the #if with #ifdef PTHREAD_ADAPTIVE_INITIALIZER_NP as recommended at [0]). There also used to be failing tests in NSPR, but some (not all) of them were related to sem_open, which nowadays should be supported by the HURD. Allowing a modern Gecko-based Browser to compile on the HURD should be a significant amount of work, up to and including porting Rust (allowing Rust to cross-compile code using only libcore and liballoc for the HURD should be relatively easy, the hard part would be porting the complete standard library and allowing the Rust compiler to run on the Hurd, I am a bit unsure whether porting liblibc is still necessary for porting libstd, if it still is, that would be an additional, significant amount of work). Best regard, Paul > Riccardo > [0]: https://lkml.kernel.org/lkml/xfmail.20010308113248.g...@syntax.dera.gov.uk/ signature.asc Description: This is a digitally signed message part
wireless setup / tools for intel wireless
Hi, I got another laptop just to run HURD (more on its status in a separate mail). I'd like to try to setup wireless, if possible. I found as reference only some very old posts. I have installed wireless-tools-gnumach, but shouldn't I have "iwconfig" with it? can't find it. # inetutils-ifconfig /dev/eth0 (2): inet address 192.168.1.146 netmask 255.255.255.0 broadcast 192.168.1.255 flags UP BROADCAST RUNNING ALLMULTI MULTICAST mtu 1500 link encap Ethernet hardware addr 00:0A:E4:C5:75:D5 lo (1): inet address 127.0.0.1 netmask 255.0.0.0 flags UP LOOPBACK RUNNING mtu 3924 link encap Local Loopback Shos only the wired ethernet and loopback, is that expected? lspci shows I have this controller: 0b:02.0 Network controller: Intel Corporation PRO/Wireless 2915ABG [Calexico2] Network Connection (rev 05) Riccardo
Re: [PATCH] Add multiboot2 header
About not seeing the GNU Mach console because the BIOS is started in graphical mode... if I understood the problem. Reading Grub doc... [This paragraph probably don't work because it says it inform Linux to use text mode] Maybe before grub-mkconfig: GRUB_GFXPAYLOAD_LINUX or using e to edit boot configuration and add: https://www.gnu.org/software/grub/manual/grub/grub.html#gfxpayload they say it set the video mode in which Linux is started... but maybe it would apply to Mach too. GRUB_TERMINAL_OUTPUT=vga_text before grub-mkconfig... I realize that if you are using a CD image... you don't easily control the grub-mkconfig part.
Re: My newly compiled Mach hang on start ext2fs:
Le mar., 09 févr. 2021 03:54:54 -0500 Samuel Thibault écrit > Paul Dufresne, le lun. 08 févr. 2021 21:08:10 -0500, a ecrit: > > Last time, after compiling my new gnumach.gz on Ubuntu, I did not tried > > it. > > > > I tested it on my QEMU environment (Gnu Hurd from this morning)... > > > > and it stop on: > > start ext2fs: > > with cursor flashsing after. > > Had you used a 32bit build of MIG? > > Samuel > Of course not, as I build on Ubuntu 64 bits, I used a 64 bit build of mig: paul@jacko:~/mymach/gnumach/gnumach/build$ file ~/gnu/libexec/migcom /home/paul/gnu/libexec/migcom: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=533d6a41a9e7f9e2e419ff168084a4f5d02ed284, for GNU/Linux 3.2.0, with debug_info, not stripped paul@jacko:~/mymach/gnumach/gnumach/build$ that was build from instructions at: https://www.gnu.org/software/hurd/microkernel/mach/mig/gnu_mig/building.html ... not: http://darnassus.sceen.net/~hurd-web/microkernel/mach/mig/gnu_mig/building/ that seems identical to me at first glance.
Re: Almost working pci-arbiter with rumpdisk
On 9/2/21 5:33 am, Samuel Thibault wrote: > Damien Zammit, le lun. 08 févr. 2021 20:33:16 +1100, a ecrit: >> I'm getting very close to working pci + rump. > > Did you manage to find answers to your previous questions? > (I have to admit I didn't have time to dive into them) I managed to remove the chicken/egg problem by not requiring the underlying node for pcifs. However, I'm still getting very stuck because I don't seem to have a "bootstrap" port for fsys_startup() in netfs for pci startup. Where would the bootstrap port come from to do the arbiter netfs_startup -> fsys_startup? As the arbiter netfs IS the bootstrap filesystem, bootstrap is NULL, or am I confused? Do I need to implement some kind of netfs_S_fsys_* ? Hurd bootstrap pci PCI machdev done PCI netfs done PCI maptime done PCI pci_system_init done XXX bootstrap is NULL pci-arbiter: Translator startup failure: fsys_startup: (ipc/send) invalid destination port Damien
Re: Re : apt-get build-dep gnumach did not install mig
Le mar., 09 févr. 2021 03:54:27 -0500 Samuel Thibault
écrit
> Paul Dufresne, le mar. 09 févr. 2021 00:06:37 -0500, a ecrit:
> > But
> > # apt-get build-dep gnumach
> > did not install mig package.
>
> Didn't it install mig-for-host and mig-i686-something?
>
> Samuel
>
>
Yes it did.
But as I was trying to reproduce what I was doing on a non-Debian system,
rather than do:
dpkg-buildpackage -us -uc -b -rfakeroot
I did: {On Debian Hurd}
autoreconf --install
mkdir build
cd build
$ GNU=~/gnu
$ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU"
that then complains it could not find mig.
So I installed mig package and complained here mig was not installed by apt-get
build-dep gnumach.
...
I was not really aware of mig-for-host and mig-i686-something...
which are for when you are on Debian Linux?
Re: PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko
On Tue, Feb 09, 2021 at 10:36:28AM +0100, Riccardo Mottola wrote: > how is compilation of Gecko related browsers going on? I am trying to > compile ArcticFox and I get this: > > 3:43.44 > /home/multix/code/Arctic-Fox/nsprpub/pr/src/pthreads/ptsynch.c:60:48: error: > ‘PTHREAD_MUTEX_ADAPTIVE_NP’ undeclared (first use in this function); did you > mean ‘PTHREAD_MUTEX_FAST_NP’? > 3:43.44 60 | rv = pthread_mutexattr_settype(&_pt_mattr, > PTHREAD_MUTEX_ADAPTIVE_NP); > 3:43.44 | ^ > 3:43.44 | PTHREAD_MUTEX_FAST_NP > > > The code is almost unchanged with current gecko, so I wonder if there were > any workarounds attempted and/or upliftable patches for that. The _NP suffix means non-posix, and is generally used for system-specific features. The use of "adaptive" mutexes is probably just an optimization, so it should be completely safe to just comment it out on systems where the macro doesn't exist (assuming it's a macro). -- Richard Braun
PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko
Hi, how is compilation of Gecko related browsers going on? I am trying to compile ArcticFox and I get this: 3:43.44 /home/multix/code/Arctic-Fox/nsprpub/pr/src/pthreads/ptsynch.c:60:48: error: ‘PTHREAD_MUTEX_ADAPTIVE_NP’ undeclared (first use in this function); did you mean ‘PTHREAD_MUTEX_FAST_NP’? 3:43.44 60 | rv = pthread_mutexattr_settype(&_pt_mattr, PTHREAD_MUTEX_ADAPTIVE_NP); 3:43.44 | ^ 3:43.44 | PTHREAD_MUTEX_FAST_NP The code is almost unchanged with current gecko, so I wonder if there were any workarounds attempted and/or upliftable patches for that. Riccardo
Re: My newly compiled Mach hang on start ext2fs:
Paul Dufresne, le lun. 08 févr. 2021 21:08:10 -0500, a ecrit: > Last time, after compiling my new gnumach.gz on Ubuntu, I did not tried it. > > I tested it on my QEMU environment (Gnu Hurd from this morning)... > > and it stop on: > start ext2fs: > with cursor flashsing after. Had you used a 32bit build of MIG? Samuel
Re: Re : apt-get build-dep gnumach did not install mig
Paul Dufresne, le mar. 09 févr. 2021 00:06:37 -0500, a ecrit: > But > # apt-get build-dep gnumach > did not install mig package. Didn't it install mig-for-host and mig-i686-something? Samuel
Re: [PATCH] Add multiboot2 header
Andrea G. Monaco, le mar. 09 févr. 2021 02:34:41 +0100, a ecrit: > Do you get that message only when using "multiboot2"? Yes. > In that case, could you please try at the grub2 prompt one line at a > time? Does the "multiboot2" line evokes any output? multiboot2 itself doesn't produce any output. The boot command then immediately reboots. It is when I try to use the module command after the multiboot2 command that I get "error: you need to load the kernel first.". Samuel
