Re: ufsutils experiment (please comment/test)
Hi, I made a little experiment to simplify ufsutils and make it easier to update. By merging ufsutils into freebsd-utils package and using its build environment, with recent freebsd-glue (0.1.4) it is now possible to build ufsutils directly from pristine upstream source: I do not mind dropping non-kfreebsd support, but I would like to keep it as a separate source package - similarly as zfsutils. Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lnx.2.00.1309090946370.13...@contest.felk.cvut.cz
Re: Multiarch on kFreeBSD?
To run a dynamically-linked mksh, ld needs to be found at /compat/linux/lib/ld-linux.so.2. Maybe it is possible to create a full set of (sym)links inside /compat/linux/ to suit the paths used by multiarch? Sounds ugly. We already have proper, non-colliding locations for i386 amd64 ld-linux.so under /lib/$(DEB_HOST_MULTIARCH)/ it should be possible to use those. I don't want to re-create multiarch libraries in /compat/, instead a Debian system should correctly load libraries from multi-arch locations. Only ld.so symlink should be needed. See also https://wiki.debian.org/Debian_GNU/kFreeBSD_FAQ#Q:_Is_it_possible_to_run_Linux_binaries_under_Debian_GNU.2FkFreeBSD_kernel.3F The kernel tries to detect whether it is a Linux binary and sometime rewrites interpretter location to /compat/... But the ld which ships with squeeze and wheezy fails with FATAL: kernel too old (we are emulating 2.6.16 syscalls). Probably a special one is needed, perhaps from the FreeBSD linux_base port? Hm... =( no idea. Maybe we will need a recompile of ld for kfreebsd platforms =/ It would just mean whole (e)glibc, as currently eglibc in Debian have for linux MIN_KERNEL_SUPPORTED := 2.6.32. Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lnx.2.00.1309090957050.13...@contest.felk.cvut.cz
Re: Bug#628493: perl: FTBFS on kfreebsd-i386: t/op/threads failed
IMO, my suggested change (Perl_atfork_reinit) in Message #54 [1] still should be aplied by perl upstream. While it might not be problem for this testcase, the unlocking in forked child is fragile. Hi, I finally (!) got round to submitting this upstream, at [1], and the comment so far is that the patch isn't appropriate. If you have any further thoughts, could you comment on the upstream RT ticket? If I remember correctly, the perl code expects something which is not guaranteed by POSIX. But our new implementation provides this, therefore we (kfreebsd) are not affected by this any longer. Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lnx.2.00.1309091011520.13...@contest.felk.cvut.cz
Re: Roll call for porters of architectures in sid and testing
Hi, I am active with the following architectures and I intend to continue this for the lifetime of the Jessie release: For kfreebsd-*, I - test a lot of packages on kfreebsd-amd64 - fix (e)glibc issues - investigate arch-specific bugs - submit fixes of arch-related bugs into BTS - co-maintain arch-related packages under the hat of the GNU/kFreeBSD Maintainers - read debian-bsd@l.d.o I am not a DD/DM. Cheers Petr Salinger -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lnx.2.00.1309091018530.13...@contest.felk.cvut.cz
Re: Multiarch on kFreeBSD?
On 09/09/13 09:10, Petr Salinger wrote: Sounds ugly. We already have proper, non-colliding locations for i386 amd64 ld-linux.so under /lib/$(DEB_HOST_MULTIARCH)/ it should be possible to use those. I don't want to re-create multiarch libraries in /compat/, instead a Debian system should correctly load libraries from multi-arch locations. Only ld.so symlink should be needed. See also https://wiki.debian.org/Debian_GNU/kFreeBSD_FAQ#Q:_Is_it_possible_to_run_Linux_binaries_under_Debian_GNU.2FkFreeBSD_kernel.3F Aha thanks. So only the squeeze version of eglibc can work. The version of eglibc from wheezy or later just segfaults if faking version 2.6.32. Multiarch paths were not used in squeeze, but with ktrace I can see it is still looking for libs in /lib/i486-linux-gnu Therefore only a couple of symlinks are needed to use multiarch (instead of a chroot) : /compat/linux/lib/ld-linux.so.2 - /lib/i386-linux-gnu/ld-linux.so.2 /compat/linux/lib/i486-linux-gnu - /lib/i386-linux-gnu That works for basic things like mksh. Possibly if you need libraries from /usr you may need more symlinks because the triplet contains i486 vs. i386 for some reason: /compat/linux/usr/lib/i486-linux-gnu - /usr/lib/i386-linux-gnu Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/522d9f79.3020...@pyro.eu.org
Re: update kfreebsd 10
Bruno Melo: well, i think it's time to bring kfreebsd 10 r254885 to test radeonkms, or not? Sure why not. Thanks for the reminder. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/522db7e2.3010...@debian.org
Bug#722246: libc6: Please consider lowering minimal linux kernel version
Package: libc6 Version: 2.17-92 Severity: wishlist Dear Maintainer, kfreebsd-i386 kfreebsd-amd64 have linux emulatrion layer that can emulate 2.6.16 linux API level. Which is also the minimum kernel version that glibc2.17 2.18 require. At configure time though, the minimal kernel version is set at 2.6.32. Would you mind lowering it back to 2.6.16? The benefits it will bring, is executing i386/amd64 binaries without need to recompile glibc, by simply enabling i386/amd64 repositories and installing foreign arch packages. I don't know what performance/size/etc penalties are with lowering minimal kernel version. Alternatively, would you consider having a separate binary glibc package on i386/amd64 with minimal version set back to 2.6.16? Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txhumbbc@debian.org
Processing of freebsd-glue_0.1.5_kfreebsd-amd64.changes
freebsd-glue_0.1.5_kfreebsd-amd64.changes uploaded successfully to localhost along with the files: freebsd-glue_0.1.5.dsc freebsd-glue_0.1.5.tar.gz freebsd-glue_0.1.5_kfreebsd-amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1vj1gu-0007h7...@franck.debian.org
freebsd-glue_0.1.5_kfreebsd-amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 09 Sep 2013 15:06:42 +0200 Source: freebsd-glue Binary: freebsd-glue Architecture: source kfreebsd-amd64 Version: 0.1.5 Distribution: unstable Urgency: low Maintainer: GNU/kFreeBSD Maintainers debian-bsd@lists.debian.org Changed-By: Robert Millan r...@debian.org Description: freebsd-glue - Emulate a FreeBSD build environment Changes: freebsd-glue (0.1.5) unstable; urgency=low . * Add include_next sys/queue.h to sys/queue.h in order to bring back macros that were disabled in kernel headers. Checksums-Sha1: b84fdc06a8e51be22ec0376ab818fcb5719bc36b 1000 freebsd-glue_0.1.5.dsc d3511574c36e1bdd6404b41364b4cbd439778c61 26584 freebsd-glue_0.1.5.tar.gz 5a7cd02174f7c1a070fd3d9cb04cf046ef3288e7 25020 freebsd-glue_0.1.5_kfreebsd-amd64.deb Checksums-Sha256: 22d3a34e6d0b340a9538adf4d10e2984f6683b889b7feb9baab85cda52528d72 1000 freebsd-glue_0.1.5.dsc 1de7cc447bd2cfd322a9703646ec9afb9c0e42cd2b3697cc2e370f9aec02b7dc 26584 freebsd-glue_0.1.5.tar.gz 5362a5e845c55e46e8406a1c006ea29e12520f48560bc37bde6b5c27c47df430 25020 freebsd-glue_0.1.5_kfreebsd-amd64.deb Files: c46762fe07c6933c031cde10b94fdeb8 1000 devel extra freebsd-glue_0.1.5.dsc ababc6d1666823799179dcbb2fad01fb 26584 devel extra freebsd-glue_0.1.5.tar.gz f5c703df09b62c5447f84bc6f9ebbe2b 25020 devel extra freebsd-glue_0.1.5_kfreebsd-amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/kFreeBSD) iEYEARECAAYFAlItyAIACgkQC19io6rUCv//AACbBjSAadykRX0BMBVbiXi/ybrt SFgAn3zE7xV9KEww+W6gf5oqpfiuu29l =mHEB -END PGP SIGNATURE- Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1vj1ls-0008iz...@franck.debian.org
Re: Bug#677046: Bug#628493: perl: FTBFS on kfreebsd-i386: t/op/threads failed
On Mon, Sep 09, 2013 at 10:14:53AM +0200, Petr Salinger wrote: IMO, my suggested change (Perl_atfork_reinit) in Message #54 [1] still should be aplied by perl upstream. While it might not be problem for this testcase, the unlocking in forked child is fragile. Hi, I finally (!) got round to submitting this upstream, at [1], and the comment so far is that the patch isn't appropriate. If you have any further thoughts, could you comment on the upstream RT ticket? If I remember correctly, the perl code expects something which is not guaranteed by POSIX. But our new implementation provides this, therefore we (kfreebsd) are not affected by this any longer. Indeed, although at one time you argued that it was a correctness fix anyway. We seem to have a consensus that that's not the case, so closing this. Cheers, Dominic. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130909202435.gw19...@urchin.earth.li
Processing of kfreebsd-10_10.0~svn255412-1_kfreebsd-amd64.changes
kfreebsd-10_10.0~svn255412-1_kfreebsd-amd64.changes uploaded successfully to localhost along with the files: kfreebsd-10_10.0~svn255412-1.dsc kfreebsd-10_10.0~svn255412.orig.tar.xz kfreebsd-10_10.0~svn255412-1.debian.tar.gz kfreebsd-source-10.0_10.0~svn255412-1_all.deb kfreebsd-headers-10.0-0_10.0~svn255412-1_kfreebsd-amd64.deb kfreebsd-image-10.0-0-amd64_10.0~svn255412-1_kfreebsd-amd64.deb kfreebsd-image-10-amd64_10.0~svn255412-1_kfreebsd-amd64.deb kfreebsd-headers-10.0-0-amd64_10.0~svn255412-1_kfreebsd-amd64.deb kfreebsd-headers-10-amd64_10.0~svn255412-1_kfreebsd-amd64.deb kernel-image-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb nic-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb nic-wireless-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb nic-shared-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb serial-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb usb-serial-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb ppp-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb cdrom-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb scsi-core-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb scsi-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb scsi-extra-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb plip-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb floppy-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb loop-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb ipv6-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb nls-core-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb ext2-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb isofs-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb reiserfs-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb fat-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb zfs-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb nfs-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb nullfs-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb md-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb parport-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb nic-usb-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb sata-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb acpi-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb i2c-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb crypto-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb crypto-dm-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb mmc-core-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb mmc-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb sound-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb zlib-modules-10.0-0-amd64-di_10.0~svn255412-1_kfreebsd-amd64.udeb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1vjao8-00036x...@franck.debian.org
kfreebsd-10_10.0~svn255412-1_kfreebsd-amd64.changes ACCEPTED into experimental
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 09 Sep 2013 14:18:49 +0200 Source: kfreebsd-10 Binary: kfreebsd-source-10.0 kfreebsd-headers-10.0-0 kfreebsd-image-10.0-0-686-smp kfreebsd-image-10-686-smp kfreebsd-headers-10.0-0-686-smp kfreebsd-headers-10-686-smp kfreebsd-image-10.0-0-amd64 kfreebsd-image-10-amd64 kfreebsd-headers-10.0-0-amd64 kfreebsd-headers-10-amd64 kernel-image-10.0-0-amd64-di nic-modules-10.0-0-amd64-di nic-wireless-modules-10.0-0-amd64-di nic-shared-modules-10.0-0-amd64-di serial-modules-10.0-0-amd64-di usb-serial-modules-10.0-0-amd64-di ppp-modules-10.0-0-amd64-di cdrom-modules-10.0-0-amd64-di scsi-core-modules-10.0-0-amd64-di scsi-modules-10.0-0-amd64-di scsi-extra-modules-10.0-0-amd64-di plip-modules-10.0-0-amd64-di floppy-modules-10.0-0-amd64-di loop-modules-10.0-0-amd64-di ipv6-modules-10.0-0-amd64-di nls-core-modules-10.0-0-amd64-di ext2-modules-10.0-0-amd64-di isofs-modules-10.0-0-amd64-di reiserfs-modules-10.0-0-amd64-di fat-modules-10.0-0-amd64-di zfs-modules-10.0-0-amd64-di nfs-modules-10.0-0-amd64-di nullfs-modules-10.0-0-amd64-di md-modules-10.0-0-amd64-di parport-modules-10.0-0-amd64-di nic-usb-modules-10.0-0-amd64-di sata-modules-10.0-0-amd64-di acpi-modules-10.0-0-amd64-di i2c-modules-10.0-0-amd64-di crypto-modules-10.0-0-amd64-di crypto-dm-modules-10.0-0-amd64-di mmc-core-modules-10.0-0-amd64-di mmc-modules-10.0-0-amd64-di sound-modules-10.0-0-amd64-di zlib-modules-10.0-0-amd64-di kfreebsd-image-10.0-0-486 kfreebsd-image-10-486 kfreebsd-headers-10.0-0-486 kfreebsd-headers-10-486 kfreebsd-image-10.0-0-686 kfreebsd-image-10-686 kfreebsd-headers-10.0-0-686 kfreebsd-headers-10-686 kfreebsd-image-10.0-0-xen kfreebsd-image-10-xen kfreebsd-headers-10.0-0-xen kfreebsd-headers-10-xen kernel-image-10.0-0-486-di nic-modules-10.0-0-486-di nic-wireless-modules-10.0-0-486-di nic-shared-modules-10.0-0-486-di serial-modules-10.0-0-486-di usb-serial-modules-10.0-0-486-di ppp-modules-10.0-0-486-di cdrom-modules-10.0-0-486-di scsi-core-modules-10.0-0-486-di scsi-modules-10.0-0-486-di scsi-extra-modules-10.0-0-486-di plip-modules-10.0-0-486-di floppy-modules-10.0-0-486-di loop-modules-10.0-0-486-di ipv6-modules-10.0-0-486-di nls-core-modules-10.0-0-486-di ext2-modules-10.0-0-486-di isofs-modules-10.0-0-486-di reiserfs-modules-10.0-0-486-di fat-modules-10.0-0-486-di zfs-modules-10.0-0-486-di nfs-modules-10.0-0-486-di nullfs-modules-10.0-0-486-di md-modules-10.0-0-486-di parport-modules-10.0-0-486-di nic-usb-modules-10.0-0-486-di sata-modules-10.0-0-486-di acpi-modules-10.0-0-486-di i2c-modules-10.0-0-486-di crypto-modules-10.0-0-486-di crypto-dm-modules-10.0-0-486-di mmc-core-modules-10.0-0-486-di mmc-modules-10.0-0-486-di sound-modules-10.0-0-486-di zlib-modules-10.0-0-486-di kfreebsd-image-10.0-0-malta kfreebsd-image-10-malta kfreebsd-headers-10.0-0-malta kfreebsd-headers-10-malta Architecture: source all kfreebsd-amd64 Version: 10.0~svn255412-1 Distribution: experimental Urgency: low Maintainer: GNU/kFreeBSD Maintainers debian-bsd@lists.debian.org Changed-By: Robert Millan r...@debian.org Description: acpi-modules-10.0-0-486-di - ACPI support modules (udeb) acpi-modules-10.0-0-amd64-di - ACPI support modules (udeb) cdrom-modules-10.0-0-486-di - Esoteric CDROM drivers (udeb) cdrom-modules-10.0-0-amd64-di - Esoteric CDROM drivers (udeb) crypto-dm-modules-10.0-0-486-di - devicemapper crypto module (udeb) crypto-dm-modules-10.0-0-amd64-di - devicemapper crypto module (udeb) crypto-modules-10.0-0-486-di - crypto modules (udeb) crypto-modules-10.0-0-amd64-di - crypto modules (udeb) ext2-modules-10.0-0-486-di - EXT2 filesystem support (udeb) ext2-modules-10.0-0-amd64-di - EXT2 filesystem support (udeb) fat-modules-10.0-0-486-di - FAT filesystem support (udeb) fat-modules-10.0-0-amd64-di - FAT filesystem support (udeb) floppy-modules-10.0-0-486-di - Floppy driver (udeb) floppy-modules-10.0-0-amd64-di - Floppy driver (udeb) i2c-modules-10.0-0-486-di - i2c support modules (udeb) i2c-modules-10.0-0-amd64-di - i2c support modules (udeb) ipv6-modules-10.0-0-486-di - IPv6 driver (udeb) ipv6-modules-10.0-0-amd64-di - IPv6 driver (udeb) isofs-modules-10.0-0-486-di - ISOFS filesystem support (udeb) isofs-modules-10.0-0-amd64-di - ISOFS filesystem support (udeb) kernel-image-10.0-0-486-di - kFreeBSD binary image for the Debian installer (udeb) kernel-image-10.0-0-amd64-di - kFreeBSD binary image for the Debian installer (udeb) kfreebsd-headers-10-486 - header files for kernel of FreeBSD 10 (meta-package) kfreebsd-headers-10-686 - header files for kernel of FreeBSD 10 (meta-package) kfreebsd-headers-10-686-smp - header files for kernel of FreeBSD 10 (transitional package) kfreebsd-headers-10-amd64 - header files for kernel of FreeBSD 10 (meta-package) kfreebsd-headers-10-malta - header files for kernel of FreeBSD 10 (meta-package) kfreebsd-headers-10-xen - header files for kernel of FreeBSD
Re: kfreebsd-10 FTBFS with clang
Christoph Egger: ../../../dev/aic7xxx/aicasm/aicasm.c:759:2: warning: implicit declaration of function 'TAILQ_INSERT_TAIL' is invalid in C99 [-Wimplicit-function-declaration] TAILQ_INSERT_TAIL(cs_tailq, new_cs, links); ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 9 warnings and 20 errors generated. *** [aicasm.o] Error code 1 Stop in /home/christoph/scratch/kfreebsd-10/flavor-10.0-0-amd64/sys/amd64/compile/DEBCUSTOM. *** [aicasm] Error code 1 Stop in /home/christoph/scratch/kfreebsd-10/flavor-10.0-0-amd64/sys/amd64/compile/DEBCUSTOM. make: *** [build-flavor-amd64-stamp] Error 1 Maybe you have an idea? Okay, this was a bug in freebsd-glue. It is fixed now... -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/522e5a07.3020...@debian.org
kfreebsd-10 built with clang (Re: kfreebsd-10_10.0~svn255412-1_kfreebsd-amd64.changes ACCEPTED into experimental)
Debian FTP Masters: kfreebsd-10 (10.0~svn255412-1) experimental; urgency=low . * New upstream snapshot. - 920_linux_cflags.diff: Set __FreeBSD__=10 in order to fix stddef.h buildability. - Switch to clang (at least until/unless GCC wmmintrin.h becomes buildable). ^^^ GCC wmmintrin.h is unbuildable in kernel because it drags in userland headers such as stdlib.h. Lacking time and ideas on how to solve this, I switched to clang-3.3 to get it building. I reckon that force majure is not the kind of clang plan we were discussing a few weeks ago... If someone has an alternate idea on what to do, please tell :-) -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/522e5e51.7010...@debian.org
Re: kfreebsd-10 built with clang (Re: kfreebsd-10_10.0~svn255412-1_kfreebsd-amd64.changes ACCEPTED into experimental)
Therefore I can use gcc to compile my programs normally and use the kernel with no problems, i agree. I agree that build it with gcc for a project called GNU/kFreeBSD is more acceptable but if it's impossible, don't lose time to build with clang ;) -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1378776107.6221.4.camel@debian
