# cd /usr/ports/et-mgmt/net-snmp # make clean configure fails with checking size of short... Segmentation fault (core dumped) configure: error: in `/usr/ports/net-mgmt/net-snmp/work/net-snmp-5.7.3': configure: error: cannot compute sizeof (short) See `config.log' for more details 'config.log' says nothing more than "configure: exit 77". The next I did was: - "make clean patch" - edit 'work/net-snmp-5.7.3/configure' and put an "echo PARAMETERS: $*" into line 2 - "make configure" - copy the parameters into a buffer - another "make clean patch" - change to 'work/net-snmp-5.7.3' - call './configure' with the above parameters This call succeeds! What is going on here?
What version of FreeBSD? Is your ports tree and all of the ports on your system up to date?
(In reply to Ryan Steinmetz from comment #1) > What version of FreeBSD? Is your ports tree and all of the ports on your system up to date? # uname -a FreeBSD packager.bs.l 10.3-STABLE FreeBSD 10.3-STABLE #0 8770436(tweaks/10): Sun Jun 12 19:07:53 CEST 2016 root@packager.bs.l:/usr/obj/usr/src/sys/GENERIC i386 8770436(tweaks/10) is some local minor changes to 2bf784f(stable/10) # ( cd /usr/src ; git show -s stable/10 ) commit 2bf784fbe867d83998b16f9744142417a6f7b49a Author: dim <dim@FreeBSD.org> Date: 2016-06-12 11:45:45 +0000 # ( cd /usr/ports ; git show -s master ) commit 0d619ed3595bc0de8412335ea3b2474fc97cc137 Author: sbz <sbz@FreeBSD.org> Date: 2016-06-14 21:19:10 +0000 The whole build is brand-new because I ran into some other trouble a week ago where just a whole pkg-delete helped. All packages were built without complaint and my package collection was complete until yet the next update produced this.
I detected that the problem surfaced when I updated the base system to 'stable/10'! When the cc in ./configure is given the option '-std=c99', it dies with a segmentation fault. Not very friendly. There's a line in 'net-mgmt/net-snmp/Makefile': USE_CSTD= c99 I replaced this with USE_CSTD= c89 Now everything works fine. Weird: Commenting out the line did not work even though the ./configure scripts CFLAGS variable didn't contain the '-std=c99'. Calling ./configure from the command line with the same CFLAGS completed flawlessly. # cc --version FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: i386-unknown-freebsd10.3 Thread model: posix
Same issue here. While I don't know what C99 compilation and linking makes different to C89, I have made more tests here with GCC 4.9.4, clang 3.4.1 (base), clang 3.7 and 3.9. Same result. My system: > FreeBSD blnn719x.ww004.siemens.net 10.3-STABLE FreeBSD 10.3-STABLE #2 r315312: > Wed Mar 15 19:59:58 CET 2017 root@blnn719x.ww004.siemens.net:/usr/obj/usr/src/sys/BLNN719X i386 Then I started looking at config.log to isolate the segmentation fault. The offending test program is generated by autoconf's AC_CHECK_SIZEOF with: > $ gcc -o conftest -fno-strict-aliasing -O2 -pipe -fno-strict-aliasing -I/usr/local/include -I/include -D_WANT_IFADDR -fstack-protector -std=c99 -Ufreebsd10 -Dfreebsd10=freebsd10 -I/usr/local/include -L/usr/local/lib -lm -lkvm -ldevstat -L/lib -L/usr/local/lib -lcrypto conftest.c -lpkg -lssp_nonshared > /usr/local/bin/ld: warning: libcrypto.so.7, needed by /usr/local/lib/libpkg.so, may conflict with libcrypto.so.9 This program is autogenerated: http://pastebin.com/ieVmL3wQ Output: > $ ./conftest > Segmentation fault (Speicherabzug geschrieben) > $ gdb ./conftest ./conftest.core > GNU gdb 6.1.1 [FreeBSD] > ... > #0 0x280f9f45 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.9 > [New Thread 29003080 (LWP 100707/<unknown>)] > (gdb) where > #0 0x280f9f45 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.9 > #1 0x287a869b in OPENSSL_ia32cap_loc () from /lib/libcrypto.so.7 > #2 0x286a0f4d in _init () from /lib/libcrypto.so.7 > #3 0x00000000 in ?? () As you can see OpenSSL is reponsible for the segfault. But wait, why do we have two libcrypto.so? Well some linked library uses OpenSSL from base while we linked OpenSSL from ports. Let's change linking to base only: > $ gcc -o conftest -fno-strict-aliasing -O2 -pipe -fno-strict-aliasing -I/usr/local/include -I/include -D_WANT_IFADDR -fstack-protector -std=c99 -Ufreebsd10 -Dfreebsd10=freebsd10 -I/usr/local/include -lm -lkvm -ldevstat -L/lib -lcrypto conftest.c -lpkg -lssp_nonshared > $ ./conftest > $ echo $? > 0 Let's check who links against OpenSSL in base: > $ ldd /usr/local/lib/libpkg.so > /usr/local/lib/libpkg.so: > libutil.so.9 => /lib/libutil.so.9 (0x28201000) > libssl.so.7 => /usr/lib/libssl.so.7 (0x28213000) > libcrypto.so.7 => /lib/libcrypto.so.7 (0x28e13000) > libm.so.5 => /lib/libm.so.5 (0x28270000) > libelf.so.1 => /usr/lib/libelf.so.1 (0x28297000) > libjail.so.1 => /lib/libjail.so.1 (0x28075000) > libarchive.so.6 => /usr/lib/libarchive.so.6 (0x282ad000) > libz.so.6 => /lib/libz.so.6 (0x28359000) > libbz2.so.4 => /usr/lib/libbz2.so.4 (0x2836f000) > liblzma.so.5 => /usr/lib/liblzma.so.5 (0x2837f000) > libc.so.7 => /lib/libc.so.7 (0x2807a000) > libthr.so.3 => /lib/libthr.so.3 (0x283a5000) > libbsdxml.so.4 => /lib/libbsdxml.so.4 (0x283c6000) Let's link with OpenSSL from ports, but without libpkg: > $ gcc -o conftest -fno-strict-aliasing -O2 -pipe -fno-strict-aliasing -I/usr/local/include -I/include -D_WANT_IFADDR -fstack-protector -std=c99 -Ufreebsd10 -Dfreebsd10=freebsd10 -I/usr/local/include -L/usr/local/lib -lm -lkvm -ldevstat -L/lib -L/usr/local/lib -lcrypto conftest.c -lssp_nonshared > $ ./conftest > $ echo $? > 0 OpenSSL: > $ /usr/bin/openssl version > OpenSSL 1.0.1u-freebsd 22 Sep 2016 > $ /usr/local/bin/openssl version > OpenSSL 1.0.2k 26 Jan 2017 Moral of the story: never mix OpenSSL versions! I am sure that OpenSSL uses static initializers when the library is loaded by ld and this is causing a mismatch. I don't know where this issue should be raised, pkg port or OpenSSL itself, but changing from C99 to C89 is just a hack. Any thoughts?
*** Bug 217779 has been marked as a duplicate of this bug. ***
The fun thing it, it works just fine on 11.0, any arch, and 10.3 amd64, the only arch it breaks is 10.3 i386.
This issue is related https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206304 I contains also a good analysis on the OpenSSL duplicate an optionally removes libpkg from the link path.
(In reply to Mathieu Arnold from comment #6) I could be a bug in OPENSSL_ia32cap_loc(). Read https://www.openssl.org/docs/man1.0.2/crypto/OPENSSL_ia32cap_loc.html > For example, clearing bit #26 at run-time disables high-performance SSE2 code present in the crypto library, while clearing bit #24 disables SSE2 code operating on 128-bit XMM register bank. You might have to do the latter if target OpenSSL application is executed on SSE2 capable CPU, but under control of OS that does not enable XMM registers. Even though you can manipulate the value programmatically, you most likely will find it more appropriate to set up an environment variable with the same name prior starting target application, e.g. on Intel P4 processor 'env OPENSSL_ia32cap=0x16980010 apps/openssl', or better yet 'env OPENSSL_ia32cap=~0x1000000 apps/openssl' to achieve same effect without modifying the application source code. Alternatively you can reconfigure the toolkit with no-sse2 option and recompile. It is worth trying to dible SSE2 on base and ports of OpenSSL and see wether it still crashes.
So friends, after reading the documentation of OpenSSL for the offensive function (https://github.com/openssl/openssl/blob/master/crypto/cryptlib.c) I started digging deeper. OpenSSL sets register EAX to 1 and reads registers ECX and EDX for CPU capability bits. Intel's documentation is quite good on this one (https://www.scss.tcd.ie/Jeremy.Jones/CS4021/processor-identification-cpuid-instruction-note.pdf, table 5-6), bit 24 of EDX denotes the capability of the CPU for > The FXSAVE and FXRSTOR instructions are > supported for fast save and restore of the floating > point context. Presence of this bit also indicates that > CR4.OSFXSR is available for an operating system to > indicate that it supports the FXSAVE and FXRSTOR > instructions. OpenSSL says here > For example, clearing bit #26 at run-time disables high-performance SSE2 code > present in the crypto library, while clearing bit #24 disables SSE2 code > operating on 128-bit XMM register bank. You might have to do the latter if > target OpenSSL application is executed on SSE2 capable CPU, but under control of OS that does not enable XMM registers So I did what OpenSSL recommended, disabled bit 24 of EDX at runtime after it has been obtained: > root@blnn719x - /usr/ports/net-mgmt/net-snmp > 2131 # env | grep OPENSSL > OPENSSL_ia32cap=~0x1000000 > make configure > ... > checking for struct rtentry.rt_use... no > checking size of short... 2 > checking size of int... 4 > checking size of long... 4 > checking size of long long... 8 > checking size of intmax_t... 8 > ... > > --------------------------------------------------------- > Net-SNMP configuration summary: > --------------------------------------------------------- > > SNMP Versions Supported: 1 2c 3 > Building for: freebsd10 > Net-SNMP Version: 5.7.3 > Network transport support: Callback Unix Alias TCP UDP IPv4Base SocketBase TCPBase UDPIPv4Base UDPBase > SNMPv3 Security Modules: usm > Agent MIB code: default_modules disman/event-mib host mibII/mta_sendmail mibII/tcpTable sctp-mib smux ucd-snmp/diskio => snmpv3mibs mibII ucd_snmp notification notification-log-mib target agent_mibs agentx disman/event disman/schedule utilities host disman/event host/hrh_storage host/hrh_filesys host/hrSWInstalledTable host/hrSWRunTable host/hr_system host/hr_device host/hr_other host/hr_proc host/hr_network host/hr_print host/hr_disk host/hr_partition mibII/ip sctp-mib/sctpScalars sctp-mib/sctpTables smux/smux util_funcs/header_simple_table > MYSQL Trap Logging: unavailable > Embedded Perl support: enabled > SNMP Perl modules: building -- embeddable > SNMP Python modules: disabled > Crypto support from: crypto > Authentication support: MD5 SHA1 > Encryption support: DES AES > Local DNSSEC validation: disabled > > --------------------------------------------------------- > Hooray! Compilation also works: > work/stage/ > |-- usr > | `-- local > | |-- bin > | | |-- agentxtrap > | | |-- encode_keychange > | | |-- fixproc > | | |-- ipf-mod.pl > | | |-- mib2c > | | |-- mib2c-update > | | |-- net-snmp-cert > | | |-- net-snmp-config > | | |-- net-snmp-create-v3-user > | | |-- snmp-bridge-mib > | | |-- snmpbulkget > | | |-- snmpbulkwalk > | | |-- snmpcheck > | | |-- snmpconf > | | |-- snmpdelta > | | |-- snmpdf > | | |-- snmpget > | | |-- snmpgetnext > | | |-- snmpinform -> snmptrap > | | |-- snmpnetstat > | | |-- snmpset > | | |-- snmpstatus > | | |-- snmptable > | | |-- snmptest > | | |-- snmptranslate > | | |-- snmptrap > | | |-- snmpusm > | | |-- snmpvacm > | | |-- snmpwalk > | | `-- traptoemail > ... It pretty much looks to me that this is a bug in the base system for i386 not properly exporting/enabling the FXSAVE and FXSTOR instructions. Unfortunately, the port does not work: > root@blnn719x - /usr/ports/net-mgmt/net-snmp/work/stage/usr/local/bin > 2146 # env | grep OPENSSL > > root@blnn719x - /usr/ports/net-mgmt/net-snmp/work/stage/usr/local/bin > 2147 # ldd snmpstatus > snmpstatus: > libnetsnmp.so.30 => /usr/local/lib/libnetsnmp.so.30 (0x28078000) > libelf.so.1 => /usr/lib/libelf.so.1 (0x28130000) > libpkg.so.4 => /usr/local/lib/libpkg.so.4 (0x28146000) > libm.so.5 => /lib/libm.so.5 (0x28359000) > libkvm.so.6 => /lib/libkvm.so.6 (0x28380000) > libdevstat.so.7 => /lib/libdevstat.so.7 (0x28389000) > libcrypto.so.9 => /usr/local/lib/libcrypto.so.9 (0x2838f000) > libc.so.7 => /lib/libc.so.7 (0x28522000) > libutil.so.9 => /lib/libutil.so.9 (0x28698000) > libssl.so.7 => /usr/lib/libssl.so.7 (0x286aa000) > libcrypto.so.7 => /lib/libcrypto.so.7 (0x28707000) > libjail.so.1 => /lib/libjail.so.1 (0x28899000) > libarchive.so.6 => /usr/lib/libarchive.so.6 (0x2889e000) > libz.so.6 => /lib/libz.so.6 (0x2894a000) > libbz2.so.4 => /usr/lib/libbz2.so.4 (0x28960000) > liblzma.so.5 => /usr/lib/liblzma.so.5 (0x28970000) > libthr.so.3 => /lib/libthr.so.3 (0x28996000) > libbsdxml.so.4 => /lib/libbsdxml.so.4 (0x289b7000) > > root@blnn719x - /usr/ports/net-mgmt/net-snmp/work/stage/usr/local/bin > 2145 # ./snmpstatus > Segmentation fault (Speicherabzug geschrieben) > > root@blnn719x - /usr/ports/net-mgmt/net-snmp/work/stage/usr/local/bin > 2149 # gdb ./snmpstatus ./snmpstatus.core > ... > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x283dbf45 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.9 > [New Thread 29003080 (LWP 101443/<unknown>)] > (gdb) where > #0 0x283dbf45 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.9 > #1 0x2885669b in OPENSSL_ia32cap_loc () from /lib/libcrypto.so.7 > #2 0x2874ef4d in _init () from /lib/libcrypto.so.7 > #3 0x00000000 in ?? () > (gdb) Let's disable bit 24 again: > root@blnn719x - /usr/ports/net-mgmt/net-snmp/work/stage/usr/local/bin > 2150 # export OPENSSL_ia32cap=~0x1000000 > > root@blnn719x - /usr/ports/net-mgmt/net-snmp/work/stage/usr/local/bin > 2151 # ./snmpstatus > No hostname specified. > USAGE: snmpstatus [OPTIONS] AGENT > > Version: 5.7.3 > ... Now let's make net-snmp think that OpenSSL from base comes from ports: > root@blnn719x - /usr/ports/net-mgmt/net-snmp/work/stage/usr/local/bin > 2150 # unset OPENSSL_ia32cap > > root@blnn719x - /usr/ports/net-mgmt/net-snmp/work/stage/usr/local/bin > 2176 # readelf -d ./snmpstatus > > Dynamic section at offset 0x2014 contains 28 entries: > Tag Type Name/Value > ... > 0x0000000f (RPATH) Library rpath: [/usr/local/lib] > ... > > root@blnn719x - /usr/ports/net-mgmt/net-snmp/work/stage/usr/local/bin > 2177 # ln -s /usr/local/lib/libcrypto.so.9 /usr/local/lib/libcrypto.so.7 > > root@blnn719x - /usr/ports/net-mgmt/net-snmp/work/stage/usr/local/bin > 2177 # ln -s /usr/local/lib/libssl.so.9 /usr/local/lib/libssl.so.7 > > root@blnn719x - /usr/ports/net-mgmt/net-snmp/work/stage/usr/local/bin > 2177 # ldd ./snmpstatus > ./snmpstatus: > libnetsnmp.so.30 => /usr/local/lib/libnetsnmp.so.30 (0x28078000) > libelf.so.1 => /usr/lib/libelf.so.1 (0x28130000) > libpkg.so.4 => /usr/local/lib/libpkg.so.4 (0x28146000) > libm.so.5 => /lib/libm.so.5 (0x28359000) > libkvm.so.6 => /lib/libkvm.so.6 (0x28380000) > libdevstat.so.7 => /lib/libdevstat.so.7 (0x28389000) > libcrypto.so.9 => /usr/local/lib/libcrypto.so.9 (0x2838f000) > libc.so.7 => /lib/libc.so.7 (0x28522000) > libutil.so.9 => /lib/libutil.so.9 (0x28698000) > libssl.so.7 => /usr/local/lib/libssl.so.7 (0x286aa000) > libjail.so.1 => /lib/libjail.so.1 (0x2870c000) > libarchive.so.6 => /usr/lib/libarchive.so.6 (0x28711000) > libz.so.6 => /lib/libz.so.6 (0x287bd000) > libbz2.so.4 => /usr/lib/libbz2.so.4 (0x287d3000) > liblzma.so.5 => /usr/lib/liblzma.so.5 (0x287e3000) > libthr.so.3 => /lib/libthr.so.3 (0x28809000) > libbsdxml.so.4 => /lib/libbsdxml.so.4 (0x2882a000 > > root@blnn719x - /usr/ports/net-mgmt/net-snmp/work/stage/usr/local/bin > 2179 # ./snmpstatus > No hostname specified. > USAGE: snmpstatus [OPTIONS] AGENT > > Version: 5.7.3 > Web: http://www.net-snmp Hooray, it works! So, OpenSSL in base IS BROKEN for me!
I am on FreeBSD blnn719x.ww004.siemens.net 10.3-STABLE FreeBSD 10.3-STABLE #2 r315312: Wed Mar 15 19:59:58 CET 2017 root@blnn719x.ww004.siemens.net:/usr/obj/usr/src/sys/BLNN719X i386 # sysctl hw.model hw.machine hw.ncpu hw.model: Intel(R) Xeon(R) CPU E5440 @ 2.83GHz hw.machine: i386 hw.ncpu: 4 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0xce3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1> AMD Features=0x20100000<NX,LM> AMD Features2=0x1<LAHF>
Instead of fiddling with env vars or symlinks, this works for me: > root@blnn719x - /usr/ports/net-mgmt/net-snmp > 2178 # svn diff > Index: Makefile > =================================================================== > --- Makefile (Revision 436263) > +++ Makefile (Arbeitskopie) > @@ -84,7 +84,7 @@ > PLIST_SUB+= WITH_PYTHON="@comment " > .endif > > -CONFIGURE_ARGS+=--with-openssl="${OPENSSLBASE}" > +CONFIGURE_ARGS+=--with-openssl="/usr" > > .if ${PORT_OPTIONS:MDUMMY} > CONFIGURE_ARGS+=--with-dummy-values
(In reply to Michael Osipov from comment #11) This is a good interim solution. I'm chatting with bapt@ about getting a mini version of libpkg created that only has the bare minimums to interact with the database (thus eliminating the openssl dependency).
A commit references this bug: Author: zi Date: Tue Mar 21 12:49:15 UTC 2017 New revision: 436596 URL: https://svnweb.freebsd.org/changeset/ports/436596 Log: - Force use of base OpenSSL for now (libpkg links against this) to resolve build failures under 10.3 i386 PR: 210299 Submitted by: Michael Osipov Reported by: software@bertram-scharpf.de Changes: head/net-mgmt/net-snmp/Makefile
(In reply to Ryan Steinmetz from comment #12) Please also be aware of what the implications are. The port is running now, but other stuff will be broken: php56-snmp-5.6.30 My httpd just crashed: > Reading symbols from /usr/local/lib/php/20131226/snmp.so...(no debugging symbols found)...done. > Loaded symbols for /usr/local/lib/php/20131226/snmp.so > Reading symbols from /usr/local/lib/libnetsnmp.so.30...(no debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libnetsnmp.so.30 > Reading symbols from /lib/libkvm.so.6...(no debugging symbols found)...done. > Loaded symbols for /lib/libkvm.so.6 > Reading symbols from /lib/libdevstat.so.7...(no debugging symbols found)...done. > Loaded symbols for /lib/libdevstat.so.7 > Reading symbols from /usr/lib/libelf.so.1...(no debugging symbols found)...done. > Loaded symbols for /usr/lib/libelf.so.1 > Reading symbols from /lib/libcrypto.so.7...(no debugging symbols found)...done. > Loaded symbols for /lib/libcrypto.so.7 > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x286b9985 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.9 > [New Thread 28c03080 (LWP 101029/<unknown>)] > (gdb) where > #0 0x286b9985 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.9 > #1 0x2a43e69b in OPENSSL_ia32cap_loc () from /lib/libcrypto.so.7 > #2 0x2a336f4d in _init () from /lib/libcrypto.so.7 > 2092 # ldd /usr/local/lib/php/20131226/snmp.so > /usr/local/lib/php/20131226/snmp.so: > libssl.so.9 => /usr/local/lib/libssl.so.9 (0x2820d000) > libnetsnmp.so.30 => /usr/local/lib/libnetsnmp.so.30 (0x2826f000) > libm.so.5 => /lib/libm.so.5 (0x28327000) > libkvm.so.6 => /lib/libkvm.so.6 (0x2834e000) > libdevstat.so.7 => /lib/libdevstat.so.7 (0x28357000) > libcrypto.so.9 => /usr/local/lib/libcrypto.so.9 (0x28c00000) > libelf.so.1 => /usr/lib/libelf.so.1 (0x2835d000) > libc.so.7 => /lib/libc.so.7 (0x2807a000) > libthr.so.3 => /lib/libthr.so.3 (0x28373000) > libcrypto.so.7 => /lib/libcrypto.so.7 (0x28d8a000) > > 2110 # less work/php-5.6.30/ext/snmp/config.log > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. > > It was created by configure, which was > generated by GNU Autoconf 2.69. Invocation command line was > > $ ./configure --with-snmp=/usr/local --with-openssl-dir=/usr/local --with-php-config=/usr/local/bin/php-config --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/ --build=i386-portbld-freebsd10.3 I had to deinstall the php56-snmp port. Ryan, can we raise this with the base maintainers?
This "solution" is going to break everything that needs snmp and openssl :( The only way to do it is to have a libpkgdb that only has the db code, but this has been a feature request for years :(
(In reply to Mathieu Arnold from comment #15) Absolutely, I don't even that Ryan would revert this patch and mark the port as BROKEN. There is no rewrite for libpkg even necessary. I think it would suffice to like libpkg against OpenSSL from ports and not from base.