> On October 16, 2015 at 3:19 AM Rainer Jung <[email protected]>
> wrote:
>
>
> Am 16.10.2015 um 06:10 schrieb dev:
>
> > So I guess the question is, on a slower older system do I need to
> > grant
> > special considerations or perhaps indicate the the timeouts on a
> > test
> > should be extended or any thoughts ?
>
> > The compile goes smooth but the tests get wedged .. badly. However
> > only
> > at test 575 and only on this old SPARC server.
>
> Just to give another data point: on our also old but stable 1280 MHz
> UltraSPARC-IIIi system (8GB Memory), the test suite runs 431 seconds
> ("TESTDONE: 994 tests were considered during 431 seconds.") on a local
>
> file system.
>
> The "remaining" output around test 575 does not indicate, that this
> test
> took especially long.
>
> A closer look reveals we are building differently, e.g. we are using
> OpenSSL instead of GnuTLS and we are not using libidn etc.
Good catch !
Yes, on the bigger faster resource rich Fujitsu server I do have GnuTLS
which I have had since 2013 :
node000$ ls -lapb /usr/local/lib | grep -i tls
-rw-r--r-- 1 root sys 1156512 Feb 24 2013 libgnutls-openssl.a
-rwxr-xr-x 1 root sys 1211 Feb 24 2013 libgnutls-openssl.la
lrwxrwxrwx 1 root sys 27 Jul 26 2013 libgnutls-openssl.so ->
libgnutls-openssl.so.27.0.2*
lrwxrwxrwx 1 root sys 27 Jul 26 2013 libgnutls-openssl.so.27
-> libgnutls-openssl.so.27.0.2*
-rwxr-xr-x 1 root sys 756936 Feb 24 2013
libgnutls-openssl.so.27.0.2
-rw-r--r-- 1 root sys 866048 Feb 24 2013 libgnutls-xssl.a
-rwxr-xr-x 1 root sys 1186 Feb 24 2013 libgnutls-xssl.la
lrwxrwxrwx 1 root sys 23 Jul 26 2013 libgnutls-xssl.so ->
libgnutls-xssl.so.0.0.0*
lrwxrwxrwx 1 root sys 23 Jul 26 2013 libgnutls-xssl.so.0 ->
libgnutls-xssl.so.0.0.0*
-rwxr-xr-x 1 root sys 548216 Feb 24 2013 libgnutls-xssl.so.0.0.0
-rw-r--r-- 1 root sys 14211608 Feb 24 2013 libgnutls.a
-rwxr-xr-x 1 root sys 1129 Feb 24 2013 libgnutls.la
lrwxrwxrwx 1 root sys 20 Jul 26 2013 libgnutls.so ->
libgnutls.so.28.16.1*
lrwxrwxrwx 1 root sys 20 Jul 26 2013 libgnutls.so.28 ->
libgnutls.so.28.16.1*
-rwxr-xr-x 1 root sys 9964760 Feb 24 2013 libgnutls.so.28.16.1
-rw-r--r-- 1 root sys 374648 Feb 24 2013 libgnutlsxx.a
-rwxr-xr-x 1 root sys 1169 Feb 24 2013 libgnutlsxx.la
lrwxrwxrwx 1 root sys 21 Jul 26 2013 libgnutlsxx.so ->
libgnutlsxx.so.28.1.0*
lrwxrwxrwx 1 root sys 21 Jul 26 2013 libgnutlsxx.so.28 ->
libgnutlsxx.so.28.1.0*
-rwxr-xr-x 1 root sys 339488 Feb 24 2013 libgnutlsxx.so.28.1.0
However the little Netra server ( hostname mimas ) does not have GnuTLS
at all.
A considerable difference.
However the resultant binaries are not particularly different :
node000$ elfdump -devl /usr/local/bin/curl
ELF Header
ei_magic: { 0x7f, E, L, F }
ei_class: ELFCLASS64 ei_data: ELFDATA2MSB
ei_osabi: ELFOSABI_SOLARIS ei_abiversion: EAV_SUNW_CURRENT
e_machine: EM_SPARCV9 e_version: EV_CURRENT
e_type: ET_EXEC
e_flags: [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ]
e_entry: 0x100003760 e_ehsize: 64 e_shstrndx: 22
e_shoff: 0x2ed88 e_shentsize: 64 e_shnum: 23
e_phoff: 0x40 e_phentsize: 56 e_phnum: 5
Version Needed Section: .SUNW_version
index file version
[2] libc.so.1 SUNW_0.7
[3] librt.so.1 SUNW_0.7
Dynamic Section: .dynamic
index tag value
[0] NEEDED 0xa98 libcurl.so.4
[1] NEEDED 0xaa5 libidn.so.11
[2] NEEDED 0xab2 libintl.so.8
[3] NEEDED 0xa7a libc.so.1
[4] NEEDED 0xabf libiconv.so.2
[5] NEEDED 0xacd libssh2.so.1
[6] NEEDED 0xada libssl.so.1.0.0
[7] NEEDED 0xaea libcrypto.so.1.0.0
[8] NEEDED 0xafd libldap.so.5
[9] NEEDED 0xb0a libz.so.1
[10] NEEDED 0xa8d librt.so.1
[11] NEEDED 0xb14 libsocket.so.1
[12] NEEDED 0xb23 libnsl.so.1
[13] INIT 0x1000133d8
[14] FINI 0x1000133e8
[15] RUNPATH 0xb2f
/usr/local/lib/$ISALIST:/usr/local/ssl/lib/$ISALIST:/usr/local/lib:/usr/local/ssl/lib:/usr/local/lib
[16] RPATH 0xb2f
/usr/local/lib/$ISALIST:/usr/local/ssl/lib/$ISALIST:/usr/local/lib:/usr/local/ssl/lib:/usr/local/lib
[17] HASH 0x100000178
[18] STRTAB 0x100001e68
[19] STRSZ 0xd94
[20] SYMTAB 0x1000008c0
[21] SYMENT 0x18
[22] CHECKSUM 0xa175
[23] VERNEED 0x100002c00
[24] VERNEEDNUM 0x2
[25] PLTRELSZ 0x918
[26] PLTREL 0x7
[27] JMPREL 0x100002e40
[28] RELA 0x100002e10
[29] RELASZ 0x948
[30] RELAENT 0x18
[31] DEBUG 0
[32] FLAGS 0 0
[33] FLAGS_1 0 0
[34] SUNW_STRPAD 0x200
[35] SUNW_LDMACH 0x2b EM_SPARCV9
[36] PLTGOT 0x100127100
[37-47] NULL 0
While the little Netra created this :
mimas$ elfdump -devl ./src/.libs/curl
ELF Header
ei_magic: { 0x7f, E, L, F }
ei_class: ELFCLASS64 ei_data: ELFDATA2MSB
ei_osabi: ELFOSABI_SOLARIS ei_abiversion: EAV_SUNW_CURRENT
e_machine: EM_SPARCV9 e_version: EV_CURRENT
e_type: ET_EXEC
e_flags: [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 ]
e_entry: 0x100003760 e_ehsize: 64 e_shstrndx: 22
e_shoff: 0x2ec88 e_shentsize: 64 e_shnum: 23
e_phoff: 0x40 e_phentsize: 56 e_phnum: 5
Version Needed Section: .SUNW_version
index file version
[2] libc.so.1 SUNW_0.7
[3] librt.so.1 SUNW_0.7
Dynamic Section: .dynamic
index tag value
[0] NEEDED 0xa98 libcurl.so.4
[1] NEEDED 0xaa5 libidn.so.11
[2] NEEDED 0xab2 libintl.so.8
[3] NEEDED 0xa7a libc.so.1
[4] NEEDED 0xabf libiconv.so.2
[5] NEEDED 0xacd libssh2.so.1
[6] NEEDED 0xada libssl.so.1.0.0
[7] NEEDED 0xaea libcrypto.so.1.0.0
[8] NEEDED 0xafd libldap.so.5
[9] NEEDED 0xb0a libz.so.1
[10] NEEDED 0xa8d librt.so.1
[11] NEEDED 0xb14 libsocket.so.1
[12] NEEDED 0xb23 libnsl.so.1
[13] INIT 0x100013330
[14] FINI 0x100013340
[15] RUNPATH 0xb2f
/usr/local/lib/$ISALIST:/usr/local/ssl/lib/$ISALIST:/usr/local/lib:/usr/local/ssl/lib:/usr/local/lib
[16] RPATH 0xb2f
/usr/local/lib/$ISALIST:/usr/local/ssl/lib/$ISALIST:/usr/local/lib:/usr/local/ssl/lib:/usr/local/lib
[17] HASH 0x100000178
[18] STRTAB 0x100001e68
[19] STRSZ 0xd94
[20] SYMTAB 0x1000008c0
[21] SYMENT 0x18
[22] CHECKSUM 0x41b2
[23] VERNEED 0x100002c00
[24] VERNEEDNUM 0x2
[25] PLTRELSZ 0x918
[26] PLTREL 0x7
[27] JMPREL 0x100002e40
[28] RELA 0x100002e10
[29] RELASZ 0x948
[30] RELAENT 0x18
[31] DEBUG 0
[32] FLAGS 0 0
[33] FLAGS_1 0 0
[34] SUNW_STRPAD 0x200
[35] SUNW_LDMACH 0x2b EM_SPARCV9
[36] PLTGOT 0x100127000
[37-47] NULL 0
No difference at all other than the usual opcode bits in e_flags of the
ELF Header.
I know that the software stack I have on the Fujitsu server runs a pile
of production, test and dev servers and they are all very very stable
and fully loaded. The little Netra server really only exists to support
some legacy gear that I have nearly everywhere. So while it would be a
massive task I have to wonder if I should scrap the toolchain on the old
Netra or perhaps just try a build on yet another server. I have a
Fujistu M4000 that would chew this all up pretty quickly.
Dennis
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
