Bug 210299 - net-mgmt/net-snmp: make configure fails
Summary: net-mgmt/net-snmp: make configure fails
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Ryan Steinmetz
URL:
Keywords:
: 217779 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-06-15 09:48 UTC by Bertram Scharpf
Modified: 2017-03-21 22:09 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (zi)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bertram Scharpf 2016-06-15 09:48:44 UTC
# 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?
Comment 1 Ryan Steinmetz freebsd_committer freebsd_triage 2016-06-15 11:12:25 UTC
What version of FreeBSD?  Is your ports tree and all of the ports on your system up to date?
Comment 2 Bertram Scharpf 2016-06-15 11:42:36 UTC
(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.
Comment 3 Bertram Scharpf 2016-06-15 18:02:52 UTC
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
Comment 4 Michael Osipov 2017-03-16 14:05:37 UTC
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?
Comment 5 Mathieu Arnold freebsd_committer 2017-03-17 08:41:14 UTC
*** Bug 217779 has been marked as a duplicate of this bug. ***
Comment 6 Mathieu Arnold freebsd_committer 2017-03-17 08:43:49 UTC
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.
Comment 7 Michael Osipov 2017-03-17 08:47:01 UTC
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.
Comment 8 Michael Osipov 2017-03-17 08:49:43 UTC
(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.
Comment 9 Michael Osipov 2017-03-17 13:58:17 UTC
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!
Comment 10 Michael Osipov 2017-03-17 14:02:57 UTC
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>
Comment 11 Michael Osipov 2017-03-21 10:46:07 UTC
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
Comment 12 Ryan Steinmetz freebsd_committer freebsd_triage 2017-03-21 12:40:15 UTC
(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).
Comment 13 commit-hook freebsd_committer 2017-03-21 12:49:35 UTC
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
Comment 14 Michael Osipov 2017-03-21 13:03:30 UTC
(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?
Comment 15 Mathieu Arnold freebsd_committer 2017-03-21 21:31:10 UTC
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 :(
Comment 16 Michael Osipov 2017-03-21 22:09:19 UTC
(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.