Re: What is xmmintrin.h, and why aren't ports finding it?
On 07 Nov 2014, at 04:36, Chris H bsd-li...@bsdforge.com wrote: Greetings, Working on a recent 11-CURRENT install (11-CURRENT #1 amd64 r274134 Nov 5 12:56:14 PST 2014) svn info /usr/ports Revision: 372176 Given the above, and the fact that I have installed lang/gcc-48. Is there any reason that any port wanting to include xmmintrin.h fails to find it? Even though dmesg messages reflects the fact that gcc48 is included within my $PATH? What you have in your PATH does not matter. The xmmintrin.h header contains SSE intrinsics, and should automatically be found by your gcc 4.8 port. Normally it is located in: /usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.4/include/xmmintrin.h or if you have a slightly different gcc version, just run: find /usr/local/lib/gcc48 -name xmmintrin.h to find it. If you run: gcc48 -v -x c -c /dev/null -o /dev/null it should show you the paths it searches for include files (look for the #include ... search starts here: line). For example, on my system this shows: #include ... search starts here: /usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.4/include /usr/local/include /usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.4/include-fixed /usr/include End of search list. The directory where you found xmmintrin.h should be listed in the search directories. -Dimitry ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
What is xmmintrin.h, and why aren't ports finding it?
Chris H writes: Working on a recent 11-CURRENT install (11-CURRENT #1 amd64 r274134 Nov 5 12:56:14 PST 2014) svn info /usr/ports Revision: 372176 Given the above, and the fact that I have installed lang/gcc-48. Is there any reason that any port wanting to include xmmintrin.h fails to find it? Even though dmesg messages reflects the fact that gcc48 is included within my $PATH? Start by looking at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190669 Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Build failed in Jenkins: FreeBSD_HEAD #1788
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1788/changes Changes: [marcel] Document that df(1) supports libxo(3). [marcel] Convert to use libxo. Obtained from: Phil Shafer p...@juniper.net Sponsored by: Juniper Networks, Inc. [marcel] Fix a SIGSEGV when emitting XML or JSON when reading stdin. In that case the file variable is NULL. [dteske] For really fast machines, an edge-case may exist where dpv(3) may be built before contrib dependency, dialog(3). Add dialog(3) to the list of _prebuild_libs to ensure that this does not happen. Tested on: 11.0-CURRENT amd64 @ r274205 Thanks to: kargl, Larry Rosenman l...@lerctr.org, ngie, markj Recommended by: ngie Reviewed by:ngie, markj MFC after: 21 days X-MFC-to: stable/10 stable/9 X-MFC-with: 274116 274120 274121 274123 274144 274146 274192 274203 -- [...truncated 143870 lines...] --- secure.all__D --- --- x_bignum.po --- --- rescue.all__D --- ld -dc -r -o id.lo id_stub.o /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/rescue/rescue//builds/FreeBSD_HEAD/usr.bin/id/id.o --- secure.all__D --- cc -pg -O2 -pipe -DTERMIOS -DANSI_SOURCE -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/secure/lib/libcrypto/../../../crypto/openssl -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DOPENSSL_IA32_SSE2 -DAES_ASM -DBSAES_ASM -DVPAES_ASM -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DMD5_ASM -DGHASH_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DWHIRLPOOL_ASM -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -std=gnu89 -fstack-protector -Wno-pointer-si gn -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1/x_bignum.c -o x_bignum.po --- rescue.all__D --- crunchide -k _crunched_id_stub id.lo --- zdb.lo --- ld -dc -r -o zdb.lo zdb_stub.o /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/rescue/rescue//builds/FreeBSD_HEAD/cddl/usr.sbin/zdb/zdb.o /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/rescue/rescue//builds/FreeBSD_HEAD/cddl/usr.sbin/zdb/zdb_il.o crunchide -k _crunched_zdb_stub zdb.lo --- chroot.lo --- ld -dc -r -o chroot.lo chroot_stub.o /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/rescue/rescue//builds/FreeBSD_HEAD/usr.sbin/chroot/chroot.o crunchide -k _crunched_chroot_stub chroot.lo --- chown.lo --- ld -dc -r -o chown.lo chown_stub.o /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/rescue/rescue//builds/FreeBSD_HEAD/usr.sbin/chown/chown.o crunchide -k _crunched_chown_stub chown.lo --- sbin.all__D --- --- bpf.o --- cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sbin/dhclient/bpf.c --- rescue.all__D --- --- rescue --- cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo bsdlabel.lo fdisk.lo dhclient.lo head.lo mt.lo nc.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo less.lo xz.lo t ar.lo vi.lo id.lo zdb.lo
Jenkins build is back to normal : FreeBSD_HEAD #1789
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1789/changes ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sh: local assignment from command loses exit status
Eric van Gyzen e...@vangyzen.net wrote:
On 11/06/2014 12:30, Fabian Keil wrote:
Eric van Gyzen e...@vangyzen.net wrote:
In sh, if I use a single statement to declare a local variable and
assign the output of a command to it, the exit status of that command is
lost. For example:
should_return_false() {
local var1=`false`
}
The function should return non-zero, but it returns zero.
The function should return the return code of the last command.
In your example, the last command is local.
Fair enough. What about errexit? The shell ran a command whose exit
status was not tested, that status was failure, yet the shell did not exit.
That's unrelated to the local, though. Compare:
fk@r500 ~ $sh -e -c 'true `false; echo Not reached`; echo Reached'
Reached
While it's not obvious from the man page[1], my assumption is that this
is intentional behaviour. The return code of the command substitution
subshell can't be checked in the parent shell, as $? belongs to the
command that gets the output as argument (in your case local),
thus counting this as an untested return code would be inconvenient.
Fabian
[1] It could be argued that the behaviour is documented as
-e ... tends to behave in unexpected ways, though ...
pgpJVnYWbgvd6.pgp
Description: OpenPGP digital signature
Re: What is xmmintrin.h, and why aren't ports finding it?
On Fri, 7 Nov 2014 13:10:51 +0100 Dimitry Andric d...@freebsd.org wrote On 07 Nov 2014, at 04:36, Chris H bsd-li...@bsdforge.com wrote: Greetings, Working on a recent 11-CURRENT install (11-CURRENT #1 amd64 r274134 Nov 5 12:56:14 PST 2014) svn info /usr/ports Revision: 372176 Given the above, and the fact that I have installed lang/gcc-48. Is there any reason that any port wanting to include xmmintrin.h fails to find it? Even though dmesg messages reflects the fact that gcc48 is included within my $PATH? What you have in your PATH does not matter. The xmmintrin.h header contains SSE intrinsics, and should automatically be found by your gcc 4.8 port. Normally it is located in: /usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.4/include/xmmintrin.h or if you have a slightly different gcc version, just run: find /usr/local/lib/gcc48 -name xmmintrin.h to find it. If you run: gcc48 -v -x c -c /dev/null -o /dev/null it should show you the paths it searches for include files (look for the #include ... search starts here: line). For example, on my system this shows: #include ... search starts here: /usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.4/include /usr/local/include /usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.4/include-fixed /usr/include End of search list. The directory where you found xmmintrin.h should be listed in the search directories. Thank you _very_ much for the reply, Dimitry. Indeed, following your example above. Indicates that xmmintrin.h _is_ in the search path. I think it must be a matter of _which_ CC USE_GCC is defaulting to. I'll have to examine things in that range, a little closer. Thank you again, for the informative reply, Dimitry. --Chris -Dimitry ___ freebsd-po...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
geli: Wrong key with a simple passphrase
Dear all, I tried to geli my external USB drive da0 with a simple passphrase But I'm getting Wrong key for da0 when I want to attach it. Let me know if I have forgot a step. Cheers,Aurelien Log -- # uname -a FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271779: Fri Sep 19 01:18:53 UTC 2014 r...@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm What I have done : # geli init da0 Enter new passphrase: Reenter new passphrase: Metadata backup can be found in /var/backups/da0.eli and ... # geli attach da0 Enter passphrase: for da0. # cat /var/backups/da0.eli | hexdump -c | head -1 000 G E O M : : E L I \0 \0 \0 \0 \0 \0 \0 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
CURRENT Revision: 274250 breaks build of x11/nvidia-driver: pkg-static: nvidia-driver-343.22 conflicts with libEGL-10.3.2
Out of the blue the build of port x11/nvidia-driver fails - portmaster is that sloppy that it can not check BEFORE it kills the existent driver and fails to install after the deletion! The src tree is at Revision: 274250 and with Revision r274177 the build works. The failure is: === Registering installation for nvidia-driver-343.22 pkg-static: nvidia-driver-343.22 conflicts with libEGL-10.3.2 (installs files into the same place). Problematic file: /usr/local/lib/libEGL.so To use these drivers, make sure that you have loaded the NVidia kernel module, by doing [...] Please can someone fix this? I have three boxes now without graphics due to this. Regards, Oliver pgpeVatCeYHF0.pgp Description: OpenPGP digital signature
CURRENT breaks build of x11/nvidia-driver: pkg-static: nvidia-driver-343.22 conflicts with libEGL-10.3.2
Out of the blue the build of port x11/nvidia-driver fails - portmaster is that sloppy that it can not check BEFORE it kills the existent driver and fails to install after the deletion! The src tree is at Revision: 274250 and with Revision r274177 the build works. The failure is: === Registering installation for nvidia-driver-343.22 pkg-static: nvidia-driver-343.22 conflicts with libEGL-10.3.2 (installs files into the same place). Problematic file: /usr/local/lib/libEGL.so To use these drivers, make sure that you have loaded the NVidia kernel module, by doing [...] Please can someone fix this? I have three boxes now without graphics due to this. Regards, Oliver pgpLrqt4O3EWt.pgp Description: OpenPGP digital signature
snapshot iso, memstick.img missing?
Hi I can't seem to find FreeBSD-11.0-CURRENT-amd64-20141025-r273635-memstick.img Any reason why this is missing? -- Johannes Lundberg -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
How exactly does the base toolchain determine WHICH language to build with?
Greetings, Sorry for the long title. I've been [needlessly] struggling with getting ports within the ports tree to build, on a fresh 11-CURRENT install from 2014-11-05. With custom KERNEL and WORLD built, and installed. Here's my situation, which has worked well since ~8.2; make.conf(5) WITHOUT_CLANG=true FAVORITE_COMPILER=gcc src.conf(5) WITHOUT_CLANG=true I'll neither argue, nor defend rational for w/o clang. To boring and out of scope for this thread. That said; I realize that lang/clang(33/34/35) is the default toolchain for 10+, and that's just fine by me. So I shouldn't be terribly surprised when install kernel/world, followed by make delete-old removes the clang built, or provided by the base install from the (initial) install procedure. But what _does_ surprise me, is that the install of lang/gcc-48 does _not_ become the compiler of choice with the above $ENV, after [seemingly] deleting clang. I understand that it may not be advisable to eliminate the default [base] toolchain. But leaving only remnants of clang, causes quite a bit of what I would consider POLA. Given that clang's bin files are [still] located in /usr/bin, while additional compilers are located in /usr/local/bin. All past installs -- even an older 11, did not exhibit this problem. What's changed? What's the rational, and how to best setup an effective build $ENV under the current circumstances? Or is this simply an [unintended] anomaly? Currently, the only way I can envision overcoming this, is by way of make.conf(5). Using the CC, CXX, and CPP directives. Which IMHO is not ideal. Thank you for all your time, and consideration, and sorry for the somewhat longish post. --Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: snapshot iso, memstick.img missing?
On Sat, Nov 08, 2014 at 08:34:17AM +0900, Lundberg, Johannes wrote: I can't seem to find FreeBSD-11.0-CURRENT-amd64-20141025-r273635-memstick.img Seconding this, I don't see it here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/11.0/ I was hoping to grab it to try booting my macbook11,1, which wasn't happy with the latest 10-series I tried on it. -- Love is a snowmobile racing across the tundra and then suddenly it flips over, pinning you underneath. At night, the ice weasels come. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: snapshot iso, memstick.img missing?
Yeah, Glen is battling build issues with mkimg. :( -adrian On 7 November 2014 15:34, Lundberg, Johannes johan...@brilliantservice.co.jp wrote: Hi I can't seem to find FreeBSD-11.0-CURRENT-amd64-20141025-r273635-memstick.img Any reason why this is missing? -- Johannes Lundberg -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: snapshot iso, memstick.img missing?
Same here. Was gonna test it on my new MacBookAir 6,1 (2014 model). -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Sat, Nov 8, 2014 at 9:26 AM, Mason Loring Bliss ma...@blisses.org wrote: On Sat, Nov 08, 2014 at 08:34:17AM +0900, Lundberg, Johannes wrote: I can't seem to find FreeBSD-11.0-CURRENT-amd64-20141025-r273635-memstick.img Seconding this, I don't see it here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/11.0/ I was hoping to grab it to try booting my macbook11,1, which wasn't happy with the latest 10-series I tried on it. -- Love is a snowmobile racing across the tundra and then suddenly it flips over, pinning you underneath. At night, the ice weasels come. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Build failed in Jenkins: FreeBSD_HEAD #1795
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1795/changes Changes: [ngie] Use PROGS instead of PROG and remove unnecessary SRCS?= assignment Using PROG instead of PROGS will in cases of high -j with -DNO_ROOT cause the PROG to show up more than once as it's handling the SCRIPTS install case in a recursive manner, separate from the non-recursive case After the recent batch of commits to bsd.progs.mk to fix behavior with how variables are defaulted to, explicitly setting SRCS for a PROG is no longer required MFC after: 1 week Reviewed by: asomers Phabric: D1130 Sponsored by: EMC / Isilon Storage Division -- [...truncated 83798 lines...] --- prgbox.o --- cc -O2 -pipe -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/gnu/lib/libdialog -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/gnu/lib/libdialog/../../../contrib/dialog -D_XOPEN_SOURCE_EXTENDED -DGCC_UNUSED=__unused -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/gnu/lib/libdialog/../../../contrib/dialog/prgbox.c -o prgbox.o --- lib/msun__L --- --- s_cbrtf.So --- cc -fpic -DPIC -O2 -pipe -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/msun/x86 -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/msun/ld80 -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/msun/src -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/msun/../libc/include -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/msun/../libc/amd64 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/msun/src/s_cbrtf.c -o s_cbrtf.So --- kerberos5/lib/libroken__L --- --- parse_units.o --- cc -O2 -pipe -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libroken/../../include -std=gnu99 -fstack-protector -Qunused-arguments -c https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_units.c -o parse_units.o --- gnu/lib/libdialog__L --- --- progressbox.o --- cc -O2 -pipe -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/gnu/lib/libdialog -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/gnu/lib/libdialog/../../../contrib/dialog -D_XOPEN_SOURCE_EXTENDED -DGCC_UNUSED=__unused -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/gnu/lib/libdialog/../../../contrib/dialog/progressbox.c -o progressbox.o --- lib/msun__L --- --- s_ceil.So --- cc -fpic -DPIC -O2 -pipe -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/msun/x86 -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/msun/ld80 -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/msun/src -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/msun/../libc/include -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/msun/../libc/amd64 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/msun/src/s_ceil.c -o s_ceil.So --- gnu/lib/libdialog__L --- --- rangebox.o --- cc -O2 -pipe -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/gnu/lib/libdialog -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/gnu/lib/libdialog/../../../contrib/dialog -D_XOPEN_SOURCE_EXTENDED -DGCC_UNUSED=__unused -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
CFR: AES-GCM and OpenCrypto work review
Hello, Over the last few months, I've been working on a project to add support for AES-GCM and AES-CTR modes to our OpenCrypto framework. The work is sponsored by The FreeBSD Foundation and Netgate. I plan on committing these patches early next week. If you need more time for review, please email me privately and I will make delay. The code has already been reviewed by Watson Ladd (the software crypto implementations) and Trevor Perrin (the aesni module part) and I have integrated these changes into the patch. There are two patches, one is the changes for OpenCrypto and the test framework. The other is the data files used by the test framework. The data is from NIST's CAVP program, and is about 20MB worth of test vectors. (I just realized, should we look at compressing these on disk?) Main patch (192KB): https://www.funkthat.com/~jmg/patches/aes.ipsec.5.patch Data files (~20MB): https://www.funkthat.com/~jmg/patches/aes.ipsec.5.testing.patch A list of notable changes in the patch: - Replacing crypto(4) w/ NetBSD's version + updates - Lots of man page updates, including CIOCFINDDEV and crypto(7) which adds specifics about restrictions on the modes. - Allow sane useage of both _HARDWARE and _SOFTWARE flags. - Add a timing safe bcmp for MAC comparision. - Add a software implementation of GCM that uses a four bit lookup table with parallelization. This algorithm is possibly vulnerable to timing attacks, but best known mitigation methods are used. Using a timing safe version is many times slower. - Added a CRYPTDEB macro that defaults to off. - Bring in some of OpenBSD's improvements to the OpenCrypto framework. - If an mbuf passed to the aesni module is only one segment, don't do a copy. This needs to be improved to support segmented buffers. - Remove the CRYPTO_F_REL flag. It was meaningless. It was used but did not change any behavior. - Add function crypto_mbuftoiov to convert an mbuf to an iov. This also converts the software crypto to only use iov's even for a simple linear buffer, and so simplifies the processing. - Add a dtrace probe for errors from the ioctl. - Add the CIOCCRYPTAEAD ioctl that allows userland processing (testing) of AES-GCM and future AEAD modes. Future improvements: - Support IV's longer than 12 bytes for GCM. - Make AES-NI support segmented buffers (iov or mbuf) so multisegmented inputs don't have to be copied. I know there are more fixes and future improvements, but can't think of them now. Ermal (eri) has patches that enable AES-GCM (and I believe AES-CTR) support for our IPsec. Once these patches have been committed, I'll work with him to integrate his patch. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Build failed in Jenkins: FreeBSD_HEAD #1795
On Nov 7, 2014, at 20:10, jenkins-ad...@freebsd.org wrote: See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1795/changes ... /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/tmp/usr/bin/ld: cannot find -lm cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [libdialog.so.8] Error code 1 make[4]: stopped in https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/gnu/lib/libdialog 1 error make[4]: stopped in https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/gnu/lib/libdialog --- lib/msun__L --- A failure has been detected in another branch of the parallel make make[4]: stopped in https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/msun --- kerberos5/lib/libroken__L --- A failure has been detected in another branch of the parallel make make[4]: stopped in https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libroken --- secure/lib/libcrypto__L --- A failure has been detected in another branch of the parallel make make[4]: stopped in https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/secure/lib/libcrypto A failure has been detected in another branch of the parallel make make[3]: stopped in https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/ *** [libraries] Error code 2 make[2]: stopped in https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/ 1 error make[2]: stopped in https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/ *** [_libraries] Error code 2 make[1]: stopped in https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/ 1 error make[1]: stopped in https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/ *** [buildworld] Error code 2 make: stopped in https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/ 1 error make: stopped in https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/ Build step 'Execute shell' marked build as failure Fixed this build race in https://svnweb.freebsd.org/base?view=revisionrevision=274270 . Thanks! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: How exactly does the base toolchain determine WHICH language to build with?
On Fri, Nov 7, 2014 at 6:23 PM, Chris H bsd-li...@bsdforge.com wrote:
Greetings,
Sorry for the long title. I've been [needlessly] struggling
with getting ports within the ports tree to build, on a
fresh 11-CURRENT install from 2014-11-05. With custom
KERNEL and WORLD built, and installed.
Here's my situation, which has worked well since ~8.2;
make.conf(5)
WITHOUT_CLANG=true
FAVORITE_COMPILER=gcc
src.conf(5)
WITHOUT_CLANG=true
I'll neither argue, nor defend rational for w/o clang. To
boring and out of scope for this thread. That said; I
realize that lang/clang(33/34/35) is the default toolchain
for 10+, and that's just fine by me. So I shouldn't be
lang/clang(33/34/35) is not the default toolchain in 10+. 10+ uses a
version of clang that is included in the FreeBSD source (/usr/src).
terribly surprised when install kernel/world, followed by
make delete-old removes the clang built, or provided by
the base install from the (initial) install procedure. But
what _does_ surprise me, is that the install of lang/gcc-48
does _not_ become the compiler of choice with the above
$ENV, after [seemingly] deleting clang. I understand that
FAVORITE_COMPILER is used by Mk/Uses/compiler.mk.
If you want ports to build with lang/gcc-48, then you would need to
check that the ports you are trying to compile have either
USES=compiler or USES_GCC defined in their Makefile. Otherwise the
ports will use the compiler that is provided by the FreeBSD source
(gcc 2.4.x or clang).
When WITHOUT_CLANG is defined in make.conf/src.conf. The FreeBSD
source will be built using gcc 2.4.x from the FreeBSD source.
/usr/bin/{cc,c++} will then be linked to the gcc versions. The ports
will then use this version to build if there is no USES_GCC or
USES=compiler in the ports Makefile.
--
DISCLAIMER:
No electrons were maimed while sending this message. Only slightly bruised.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: How exactly does the base toolchain determine WHICH language to build with?
On Fri, 7 Nov 2014 22:39:27 -0600 Scot Hetzel swhet...@gmail.com wrote
On Fri, Nov 7, 2014 at 6:23 PM, Chris H bsd-li...@bsdforge.com wrote:
Greetings,
Sorry for the long title. I've been [needlessly] struggling
with getting ports within the ports tree to build, on a
fresh 11-CURRENT install from 2014-11-05. With custom
KERNEL and WORLD built, and installed.
Here's my situation, which has worked well since ~8.2;
make.conf(5)
WITHOUT_CLANG=true
FAVORITE_COMPILER=gcc
src.conf(5)
WITHOUT_CLANG=true
I'll neither argue, nor defend rational for w/o clang. To
boring and out of scope for this thread. That said; I
realize that lang/clang(33/34/35) is the default toolchain
for 10+, and that's just fine by me. So I shouldn't be
lang/clang(33/34/35) is not the default toolchain in 10+. 10+ uses a
version of clang that is included in the FreeBSD source (/usr/src).
terribly surprised when install kernel/world, followed by
make delete-old removes the clang built, or provided by
the base install from the (initial) install procedure. But
what _does_ surprise me, is that the install of lang/gcc-48
does _not_ become the compiler of choice with the above
$ENV, after [seemingly] deleting clang. I understand that
FAVORITE_COMPILER is used by Mk/Uses/compiler.mk.
If you want ports to build with lang/gcc-48, then you would need to
check that the ports you are trying to compile have either
USES=compiler or USES_GCC defined in their Makefile. Otherwise the
ports will use the compiler that is provided by the FreeBSD source
(gcc 2.4.x or clang).
When WITHOUT_CLANG is defined in make.conf/src.conf. The FreeBSD
source will be built using gcc 2.4.x from the FreeBSD source.
/usr/bin/{cc,c++} will then be linked to the gcc versions. The ports
will then use this version to build if there is no USES_GCC or
USES=compiler in the ports Makefile.
Perfect, and thank you very much, Scott, for the clarification.
For what ever reason. Mine (CC,cc++,...) are linked to what's left
of clang. I guess I'll need to try and dig deeper, and see if I can
discover, why, and what happened.
Just for the record. Re-reading my comment above, I realize that
my statement regarding clang, might be interpreted as my having
negative feelings about clang/llvm. For clarity, that is not the
case. This install is targeted at development. As such, I want
more granular control of what I build, and test with. So I'll
actually be installing every version of lang/clang, and testing
accordingly.
Thank you again, Scott, for taking the time to respond.
--Chris
--
DISCLAIMER:
No electrons were maimed while sending this message. Only slightly bruised.
___
freebsd-po...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
