bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] Wget 1.13.4 on True64 OSF1 Beta


From: Steven M. Schweda
Subject: Re: [Bug-wget] Wget 1.13.4 on True64 OSF1 Beta
Date: Wed, 18 Apr 2012 12:02:55 -0500 (CDT)

> I have installed the above version on our True 64 [...]

   Did you notice that saying "the above version" actually requires more
space than repeating some useful information?  Do you mean "Tru64"?  If
so, then:

      sizer -v

And what, exactly, does "installed" mean in this case?  Which compiler
did you use?  How did you configure the build?  As usual, showing actual
commands with their actual output can be more helpful than vague
descriptions or interpretations.

   What makes you say "Beta"?  The "B" in "V5.1B" what comes after the
"A" in "V5.1A" (and "V5.1A" is what came after plain-old "V5.1".)

   Around here:

urtx# sizer -v
HP Tru64 UNIX V5.1B (Rev. 2650); Fri Mar 20 20:19:48 CDT 2009

urtx# cc -V
Compaq C V6.5-303 (dtk) on HP Tru64 UNIX V5.1B (Rev. 2650)
Compiler Driver V6.5-302 (dtk) cc Driver

   I built this stuff back around "Sep 23  2011", but I apparently never
did _any_ testing, because I see the same problem here.  (I seldom use
Tru64 these days.)

urtx# pwd
/usr/local/src/wget/wget-1.13.4

urtx# ./src/wget -V
GNU Wget 1.13.4 built on osf5.1b.

+digest +https +ipv6 -iri +large-file +nls +ntlm +opie +ssl/openssl

Wgetrc:
    /usr/local/etc/wgetrc (system)
Locale: /usr/local/share/locale
Compile: cc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/usr/local/etc/wgetrc"
    -DLOCALEDIR="/usr/local/share/locale" -I. -I../lib -I../lib
    -I/usr/local/include -I/usr/local/src/wget/ossl/include -O -Olimit 
    2000
Link: cc -O -Olimit 2000 /usr/local/lib/libiconv.so -rpath /usr/local/lib
    /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -lc -rpath
    /usr/local/lib /usr/local/src/wget/ossl/lib/libssl.a
    /usr/local/src/wget/ossl/lib/libcrypto.a -lz -lz -lrt -lrt
    ftp-opie.o openssl.o http-ntlm.o ../lib/libgnu.a

Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://www.gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Originally written by Hrvoje Niksic <address@hidden>.
Please send bug reports and questions to <address@hidden>.


urtx# ./src/wget ftp://alp-l/announce.txt
--2012-04-18 10:25:04--  ftp://alp-l/announce.txt
           => `announce.txt'
Resolving alp-l... 10.0.0.9
Connecting to alp-l|10.0.0.9|:21... failed: Address family not supported by prot
ocol family.

   That was startling.

   The problem seems to originate in "netinet/in.h":

[...]
/*
 * Socket address, internet style.
 */
#if defined(_SOCKADDR_LEN) || defined(_KERNEL) || \
                        defined(_XOPEN_SOURCE_EXTENDED)
struct sockaddr_in {
        unsigned char   sin_len;
        sa_family_t     sin_family;     /* New typedef for Spec 1170 */
        in_port_t       sin_port;       /* New typedef for Spec 1170 */
        struct  in_addr sin_addr;
#ifdef _XOPEN_SOURCE_EXTENDED
        unsigned char   sin_zero[8];    /* Changed type from char to     */
                                        /* unsigned char for Spec 1170   */
#else
        char    sin_zero[8];
#endif
};
#else
struct sockaddr_in {
        unsigned short  sin_family;
        unsigned short  sin_port;
        struct  in_addr sin_addr;
        char    sin_zero[8];
};
#endif
[...]

Thus, with none of the macros _SOCKADDR_LEN, _KERNEL, or
_XOPEN_SOURCE_EXTENDED defined, "struct sockaddr_in" does not include
the "sin_len" member, so it's incompatible with a plain
"struct sockaddr", and connect.c:sockaddr_set_data() stores AF_INET at
the wrong offset in the actual sockaddr structure, which confuses
everyone.

   As an instant work-around, I manually defined _SOCKADDR_LEN at
configure time, and re-built:

urtx# ./configure CC=cc CFLAGS='-O -D_SOCKADDR_LEN' --with-ssl=openssl \
 --with-libssl-prefix=/usr/local/src/wget/ossl 2>&1 | \
 tee ../wget-1.13.4_cc_urtx_configure_ossl_6.log

urtx# gmake 2>&1 | tee ../wget-1.13.4_cc_urtx_gmake_6.log


   The result seems to be less horrible:

urtx# src/wget ftp://alp-l/announce.txt
--2012-04-18 12:01:25--  ftp://alp-l/announce.txt
           => `announce.txt'
Resolving alp-l... 10.0.0.9
Connecting to alp-l|10.0.0.9|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD not needed.
==> SIZE announce.txt ... done.
==> PASV ... done.    ==> RETR announce.txt ... done.

    [ <=>                                   ] 41          --.-K/s   in 0s

2012-04-18 12:01:26 (820 B/s) - `announce.txt' saved [41]


   Assuming that this might conceivably happen on some other system
type, the right answer may be to add (yet) another feature test to
"configure", to see if a "struct sockaddr_in" has a "sin_len" member,
and, if not, then add "-D_SOCKADDR_LEN" to CFLAGS.

   I assume that "sin_len" is a standard member name.  If not, then it
may make more sense to define _SOCKADDR_LEN on Tru64 ("*osf*") along
with the other stuff in the OS-specific mess: 

[...]
    case "$host_os" in
      *hpux*)  CFLAGS="$CFLAGS +O3"                      ;;
      *ultrix* | *osf*) CFLAGS="$CFLAGS -O -Olimit 2000" ;;
      *)       CFLAGS="$CFLAGS -O" ;;
[...]


   That was fun _and_ educational.

------------------------------------------------------------------------

   Steven M. Schweda               address@hidden
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547



reply via email to

[Prev in Thread] Current Thread [Next in Thread]