[Bug-wget] Problems with (not) building wget against libiconv
Hi, I'm experiencing a recent regression in wget builds. It worked fine in version 1.17.1 and it fails now with 1.19.1. I can do some bisection, but I guess I could blame at least the following commit: http://git.savannah.gnu.org/cgit/wget.git/commit/src/url.c?id=7e585fe23dd69cadfc3f44df0c5f8bc47ab37cbb that has not been properly restored in http://git.savannah.gnu.org/cgit/wget.git/commit/src/url.c?id=517d799b6f94e60e302806a2daa14c7a4ac3fbbd but more importantly: m4/gnulib-comp.m4 seems to opportunistically define HAVE_ICONV even if I try to do my best not to. We need portable wget binaries just for the sake of downloading a few packages. This is why we try to exclude as many libraries as possible (the only other alternative would be to build them statically). The biggest problem arises when the build machine has a certain package that cannot be found on the target machine. We configure wget with --enable-ipv6 --disable-iri --disable-nls --disable-ntlm --disable-pcre --without-libiconv-prefix --without-libintl-prefix --without-libuuid --without-libpsl --without-ssl --without-zlib and the build fails both on Solaris 10 (on the same buildfarm as you are using) and on Mac OS X 10.6. Both say: checking for iconv.h... yes And then fail in the last step (with url.o containing iconv symbols). Solaris: CCLD wget Undefined first referenced symbol in file libiconv_close url.o (symbol belongs to implicit dependency /opt/csw/lib/gcc/i386-pc-solaris2.10/5.2.0/../../../libiconv.so.2) libiconv_open url.o (symbol belongs to implicit dependency /opt/csw/lib/gcc/i386-pc-solaris2.10/5.2.0/../../../libiconv.so.2) libiconvurl.o (symbol belongs to implicit dependency /opt/csw/lib/gcc/i386-pc-solaris2.10/5.2.0/../../../libiconv.so.2) ld: fatal: symbol referencing errors. No output written to wget collect2: error: ld returned 1 exit status Mac: CCLD wget Undefined symbols: "_iconv_close", referenced from: _convert_fname in url.o _convert_fname in url.o "_iconv", referenced from: _convert_fname in url.o _convert_fname in url.o "_iconv_open", referenced from: _convert_fname in url.o ld: symbol(s) not found collect2: ld returned 1 exit status I would be grateful if this could be fixed. Mojca
Re: [Bug-wget] Problems with (not) building wget against libiconv
On Samstag, 15. April 2017 22:36:33 CEST Mojca Miklavec wrote: > Hi, > > I'm experiencing a recent regression in wget builds. It worked fine in > version 1.17.1 and it fails now with 1.19.1. > > I can do some bisection, but I guess I could blame at least the > following commit: > > http://git.savannah.gnu.org/cgit/wget.git/commit/src/url.c?id=7e585fe23dd69c > adfc3f44df0c5f8bc47ab37cbb > > that has not been properly restored in > > http://git.savannah.gnu.org/cgit/wget.git/commit/src/url.c?id=517d799b6f94e6 > 0e302806a2daa14c7a4ac3fbbd > > but more importantly: m4/gnulib-comp.m4 seems to opportunistically > define HAVE_ICONV even if I try to do my best not to. > > > We need portable wget binaries just for the sake of downloading a few > packages. This is why we try to exclude as many libraries as possible > (the only other alternative would be to build them statically). The > biggest problem arises when the build machine has a certain package > that cannot be found on the target machine. > > We configure wget with > > --enable-ipv6 --disable-iri --disable-nls --disable-ntlm > --disable-pcre --without-libiconv-prefix --without-libintl-prefix > --without-libuuid --without-libpsl --without-ssl --without-zlib > > and the build fails both on Solaris 10 (on the same buildfarm as you > are using) and on Mac OS X 10.6. > > Both say: > checking for iconv.h... yes > > And then fail in the last step (with url.o containing iconv symbols). > > Solaris: > > CCLD wget > Undefined first referenced > symbol in file > libiconv_close url.o (symbol belongs to implicit > dependency > /opt/csw/lib/gcc/i386-pc-solaris2.10/5.2.0/../../../libiconv.so.2) > libiconv_open url.o (symbol belongs to implicit > dependency > /opt/csw/lib/gcc/i386-pc-solaris2.10/5.2.0/../../../libiconv.so.2) libiconv >url.o (symbol belongs to implicit dependency > /opt/csw/lib/gcc/i386-pc-solaris2.10/5.2.0/../../../libiconv.so.2) ld: > fatal: symbol referencing errors. No output written to wget > collect2: error: ld returned 1 exit status > > > Mac: > > CCLD wget > Undefined symbols: > "_iconv_close", referenced from: > _convert_fname in url.o > _convert_fname in url.o > "_iconv", referenced from: > _convert_fname in url.o > _convert_fname in url.o > "_iconv_open", referenced from: > _convert_fname in url.o > ld: symbol(s) not found > collect2: ld returned 1 exit status > > > I would be grateful if this could be fixed. Hi Mojca, of course we try to fix this. The first step is to reproduce the problem. I just tried on this build farm on 'unstable10x' (Solaris 10) with exactly the configure flags from above. All compiled well. What am I doing wrong (or what are you doing wrong ?) Configure summary: Version: 1.19.1.23-b2c38 Host OS: solaris2.10 Install prefix:/usr/local Compiler: gcc CFlags:-I/opt/csw/include -I/opt/csw/include -DNDEBUG - D_REENTRANT LDFlags: Libs: -L/opt/csw/lib -lgpgme -lassuan -lsocket -lgpg-error -L/ opt/csw/lib -lmetalink SSL: no Zlib: no PSL: no Digest:yes NTLM: no OPIE: yes POSIX xattr: no Debugging: yes Assertions:no Valgrind: Valgrind testing not enabled Metalink: yes Resolver: libc, --bind-dns-address and --dns-servers not available GPGME: yes IRI: no Also, you might add --disable-metalink to avoid libgpgme. Regards, Tim signature.asc Description: This is a digitally signed message part.
Re: [Bug-wget] Problems with (not) building wget against libiconv
On 16 April 2017 at 00:07, Tim Rühsen wrote: > On Samstag, 15. April 2017 22:36:33 CEST Mojca Miklavec wrote: >> Hi, >> >> I'm experiencing a recent regression in wget builds. It worked fine in >> version 1.17.1 and it fails now with 1.19.1. >> >> We configure wget with >> >> --enable-ipv6 --disable-iri --disable-nls --disable-ntlm >> --disable-pcre --without-libiconv-prefix --without-libintl-prefix >> --without-libuuid --without-libpsl --without-ssl --without-zlib >> >> and the build fails both on Solaris 10 (on the same buildfarm as you >> are using) and on Mac OS X 10.6. >> >> Both say: >> checking for iconv.h... yes >> >> And then fail in the last step (with url.o containing iconv symbols). > > of course we try to fix this. > > The first step is to reproduce the problem. I just tried on this build farm on > 'unstable10x' (Solaris 10) with exactly the configure flags from above. > > All compiled well. What am I doing wrong (or what are you doing wrong ?) I didn't add any flags like I see them in your summary (I want to avoid linking against any of those libraries anyway): -I/opt/csw/include -I/opt/csw/include -L/opt/csw/lib -lgpgme -lassuan -lsocket -lgpg-error -L/opt/csw/lib -lmetalink Another difference is that I don't have /opt/csw/gnu in PATH, but I don't think that makes any difference in this case. I can send full logs for comparison if needed. > Configure summary: > Version: 1.19.1.23-b2c38 > Host OS: solaris2.10 > Install prefix:/usr/local > Compiler: gcc > CFlags:-I/opt/csw/include -I/opt/csw/include -DNDEBUG - > D_REENTRANT > LDFlags: > Libs: -L/opt/csw/lib -lgpgme -lassuan -lsocket -lgpg-error -L/ > opt/csw/lib -lmetalink > SSL: no > Zlib: no > PSL: no > Digest:yes > NTLM: no > OPIE: yes > POSIX xattr: no > Debugging: yes > Assertions:no > Valgrind: Valgrind testing not enabled > Metalink: yes > Resolver: libc, --bind-dns-address and --dns-servers not available > GPGME: yes > IRI: no Version: 1.19.1 Host OS: solaris2.10 Install prefix:/usr/local Compiler: /opt/csw/bin/gcc-5.2 CFlags:-DNDEBUG -D_REENTRANT LDFlags: Libs: SSL: no Zlib: no PSL: no Digest:yes NTLM: no OPIE: yes POSIX xattr: no Debugging: yes Assertions:no Valgrind: Valgrind testing not enabled Metalink: no Resolver: libc, --bind-dns-address and --dns-servers not available GPGME: no IRI: no Mojca
Re: [Bug-wget] Problems with (not) building wget against libiconv
On Sonntag, 16. April 2017 00:24:22 CEST Mojca Miklavec wrote: > On 16 April 2017 at 00:07, Tim Rühsen wrote: > > On Samstag, 15. April 2017 22:36:33 CEST Mojca Miklavec wrote: > >> Hi, > >> > >> I'm experiencing a recent regression in wget builds. It worked fine in > >> version 1.17.1 and it fails now with 1.19.1. > >> > >> We configure wget with > >> > >> --enable-ipv6 --disable-iri --disable-nls --disable-ntlm > >> --disable-pcre --without-libiconv-prefix --without-libintl-prefix > >> --without-libuuid --without-libpsl --without-ssl --without-zlib > >> > >> and the build fails both on Solaris 10 (on the same buildfarm as you > >> are using) and on Mac OS X 10.6. > >> > >> Both say: > >> checking for iconv.h... yes > >> > >> And then fail in the last step (with url.o containing iconv symbols). > > > > of course we try to fix this. > > > > The first step is to reproduce the problem. I just tried on this build > > farm on 'unstable10x' (Solaris 10) with exactly the configure flags from > > above. > > > > All compiled well. What am I doing wrong (or what are you doing wrong ?) > > I didn't add any flags like I see them in your summary (I want to > avoid linking against any of those libraries anyway): > > -I/opt/csw/include -I/opt/csw/include > -L/opt/csw/lib -lgpgme -lassuan -lsocket -lgpg-error > -L/opt/csw/lib -lmetalink > > Another difference is that I don't have /opt/csw/gnu in PATH, but I > don't think that makes any difference in this case. I can send full > logs for comparison if needed. > > > Configure summary: > > Version: 1.19.1.23-b2c38 > > Host OS: solaris2.10 > > Install prefix:/usr/local > > Compiler: gcc > > CFlags:-I/opt/csw/include -I/opt/csw/include -DNDEBUG - > > > > D_REENTRANT > > > > LDFlags: > > Libs: -L/opt/csw/lib -lgpgme -lassuan -lsocket -lgpg-error > > -L/ > > > > opt/csw/lib -lmetalink > > > > SSL: no > > Zlib: no > > PSL: no > > Digest:yes > > NTLM: no > > OPIE: yes > > POSIX xattr: no > > Debugging: yes > > Assertions:no > > Valgrind: Valgrind testing not enabled > > Metalink: yes > > Resolver: libc, --bind-dns-address and --dns-servers not > > available > > GPGME: yes > > IRI: no > > Version: 1.19.1 > Host OS: solaris2.10 > Install prefix:/usr/local > Compiler: /opt/csw/bin/gcc-5.2 > CFlags:-DNDEBUG -D_REENTRANT > LDFlags: > Libs: > SSL: no > Zlib: no > PSL: no > Digest:yes > NTLM: no > OPIE: yes > POSIX xattr: no > Debugging: yes > Assertions:no > Valgrind: Valgrind testing not enabled > Metalink: no > Resolver: libc, --bind-dns-address and --dns-servers not > available GPGME: no > IRI: no > > Mojca The question was more on which OpenCWS machine did you test (you said you are using the same build platform !? on 'unstable10x' was my test, libraries have been automatically detected). My configure call: ./configure --enable-ipv6 --disable-iri --disable-nls --disable-ntlm --disable- pcre --without-libiconv-prefix --without-libintl-prefix --without-libuuid -- without-libpsl --without-ssl --without-zlib Regards, Tim signature.asc Description: This is a digitally signed message part.
Re: [Bug-wget] Problems with (not) building wget against libiconv
On 16 April 2017 at 09:27, Tim Rühsen wrote: > > The question was more on which OpenCWS machine did you test (you said you are > using the same build platform !? on 'unstable10x' was my test, libraries have > been automatically detected). Yes, unstable10x. I suspect unstable10s would have the same problem, I can try. (But perhaps with slightly different environmental variables? Because your configure report shows additional libraries that mine doesn't.) I didn't use any map files this time (I should use them for the final build). The problem is reproducible at least on Mac and FreeBSD. Another Mac user reported that the problem went away after removing --disable-iri, but I guess that means linking against libiconv (which isn't available on Solaris by default and thus the binary would fail to work when there's no package management available). Mojca
Re: [Bug-wget] Problems with (not) building wget against libiconv
On Sonntag, 16. April 2017 10:00:05 CEST Mojca Miklavec wrote: > On 16 April 2017 at 09:27, Tim Rühsen wrote: > > The question was more on which OpenCWS machine did you test (you said you > > are using the same build platform !? on 'unstable10x' was my test, > > libraries have been automatically detected). > > Yes, unstable10x. I suspect unstable10s would have the same problem, I > can try. (But perhaps with slightly different environmental variables? > Because your configure report shows additional libraries that mine > doesn't.) > > I didn't use any map files this time (I should use them for the final > build). > > The problem is reproducible at least on Mac and FreeBSD. Another Mac > user reported that the problem went away after removing --disable-iri, > but I guess that means linking against libiconv (which isn't available > on Solaris by default and thus the binary would fail to work when > there's no package management available). First, let's find out why it works on my setup (I didn't setup anything except 2 aliases, but maybe Dagobert Michelsen did that for me). Maybe you can compare with your settings > cat .bash_profile alias l='ls -la --color' alias make='make -j10' set +o ignoreeof export RSYNC_PROXY=proxy:3128 PKG_CONFIG_PATH=/opt/csw/lib/pkgconfig PATH=/opt/csw/gnu:/opt/csw/bin:$PATH:~/bin export LC_ALL=en_US.UTF-8 export LANG=en_US.UTF-8 export LANGUAGE=en_US.UTF-8 > set BASH=/opt/csw/bin/bash BASHOPTS=cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:login_shell:progcomp:promptvars:sourcepath BASH_ALIASES=() BASH_ARGC=() BASH_ARGV=() BASH_CMDS=() BASH_LINENO=() BASH_SOURCE=() BASH_VERSINFO=([0]="4" [1]="3" [2]="33" [3]="1" [4]="release" [5]="i386-pc- solaris2.10") BASH_VERSION='4.3.33(1)-release' BASICSETTINGS=/etc/environment/default-settings COLUMNS=142 DIRSTACK=() DISPLAY=localhost:10.0 EDITOR=vi EUID=11058 FCEDIT=vi FIGNORE='~:.o:.orig:.ori:.old:.backup' GROUPS=() HISTCONTROL=ignoreboth HISTFILE=/home/rockdaboot/.bash_history HISTFILESIZE=500 HISTSIZE=500 HOME=/home/rockdaboot HOSTNAME=unstable10x HOSTTYPE=i386 IFS=$' \t\n' LANG=en_US.UTF-8 LANGUAGE=en_US.UTF-8 LC_ALL=en_US.UTF-8 LESS=MQi LINES=46 LOGNAME=rockdaboot MACHTYPE=i386-pc-solaris2.10 MAIL=/var/mail//rockdaboot MAILCHECK=60 MANPATH=/usr/man:/usr/dt/man:/usr/openwin/man:/opt/SUNWspro/man:/opt/csw/man:/ usr/sfw/man MLIBHOME=/opt/SUNWmlib OPTERR=1 OPTIND=1 OSTYPE=solaris2.10 PAGER=less PATH=/opt/csw/gnu:/opt/csw/bin:/usr/bin:/usr/sbin:/sbin:/usr/ccs/bin:/usr/dt/ bin:/usr/openwin/bin:/opt/SUNWspro/bin:/opt/bop/bin:/opt/csw/bin:/usr/sfw/ bin:/usr/sfw/sbin:/home/rockdaboot/bin PIPESTATUS=([0]="0") PKG_CONFIG_PATH=/opt/csw/lib/pkgconfig PPID=6886 PS1='\[\e[1m\]\u\[\e[0m\]@\H [\[\e[1m\]global\[\e[0m\]]:\[\e[1m\]\w\[\e[0m\] > ' PS2='continued> ' PS3='select> ' PS4='+ ' PWD=/home/rockdaboot RSYNC_PROXY=proxy:3128 SEDEBUG=0 SHELL=/opt/csw/bin/bash SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive- comments:monitor SHLVL=1 SSHAGENT=/usr/bin/ssh-agent SSH_CLIENT='192.168.1.2 37275 22' SSH_CONNECTION='192.168.1.2 37275 192.168.1.33 22' SSH_TTY=/dev/pts/2 TERM=xterm-256color TZ=Europe/Berlin UID=11058 USER=rockdaboot VISUAL=vi ZONENAME='[\[\e[1m\]global\[\e[0m\]]' _=LANGUAGE rockdaboot@unstable10x [global]:~ > setenv -bash: setenv: command not found rockdaboot@unstable10x [global]:~ > cat .bash_ .bash_history .bash_profile rockdaboot@unstable10x [global]:~ > cat .bash_profile alias l='ls -la --color' alias make='make -j10' set +o ignoreeof export RSYNC_PROXY=proxy:3128 PKG_CONFIG_PATH=/opt/csw/lib/pkgconfig PATH=/opt/csw/gnu:/opt/csw/bin:$PATH:~/bin export LC_ALL=en_US.UTF-8 export LANG=en_US.UTF-8 export LANGUAGE=en_US.UTF-8 From what I saw in your config.log, both HAVE_ICONV_H and HAVE_ICONV are defined. Obviously -liconv does work with your settings. So I am still confused and the best things would be to have those settings to reproduce the problem. Regards, Tim signature.asc Description: This is a digitally signed message part.
Re: [Bug-wget] Problems with (not) building wget against libiconv
On Sonntag, 16. April 2017 10:00:05 CEST Mojca Miklavec wrote: > On 16 April 2017 at 09:27, Tim Rühsen wrote: > > The question was more on which OpenCWS machine did you test (you said you > > are using the same build platform !? on 'unstable10x' was my test, > > libraries have been automatically detected). > > Yes, unstable10x. I suspect unstable10s would have the same problem, I > can try. (But perhaps with slightly different environmental variables? > Because your configure report shows additional libraries that mine > doesn't.) > > I didn't use any map files this time (I should use them for the final > build). > > The problem is reproducible at least on Mac and FreeBSD. Also I can't reproduce the issue on FreeBSD 11. ./configure summary: Version: 1.19.1.23-b2c38-dirty Host OS: freebsd11.0 Install prefix:/usr/local Compiler: cc CFlags:-DNDEBUG -D_THREAD_SAFE LDFlags: Libs: SSL: no Zlib: no PSL: no Digest:yes NTLM: no OPIE: yes POSIX xattr: yes Debugging: yes Assertions:no Valgrind: Valgrind testing not enabled Metalink: no Resolver: libc, --bind-dns-address and --dns-servers not available GPGME: no IRI: no Please make sure, you test with latest wget git. Regards, Tim signature.asc Description: This is a digitally signed message part.
Re: [Bug-wget] Problems with (not) building wget against libiconv
On 16 April 2017 at 18:54, Tim Rühsen wrote: > > Please make sure, you test with latest wget git. I have some problems with bootstrapping. On Solaris it's: > ./bootstrap ./bootstrap: syntax error at line 91: `me_=$' unexpected On Mac it's: sed: 1: "lib/unicase/special-cas ...": extra characters at the end of l command ./bootstrap: bootstrap_post_import_hook failed I added an empty string before the command, but I'm not sure if that's the right thing to do: sed -i "" "s/gl_unicase_special_lookup.*/gl_unicase_special_lookup\ \(const char \*str, size_t len\)/g" lib/unicase/special-casing-table.h After that the build succeeds, but it's linking against libiconv (contrary to --without-libiconv-prefix): > otool -L wget wget: /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11) On Mac that should be OK (I hope), but on Solaris there is no libiconv by default. I copiled a folder with bootstrapped wget to the Solaris box, but as expected I ended up with: > ldd src/wget libsocket.so.1 =>/lib/libsocket.so.1 libnsl.so.1 => /lib/libnsl.so.1 librt.so.1 =>/lib/librt.so.1 libiconv.so.2 => /opt/csw/lib/libiconv.so.2 libunistring.so.2 => /opt/csw/lib/libunistring.so.2 ... And having libraries from /opt/csw there is simply not acceptable since the binaries won't work on machines without OpenCSW installed. So my next question would be: how can I get rid of dependency on libiconv? I didn't have this problem in version 1.17.1. Repeating the configure string: --enable-ipv6 --disable-iri --disable-nls --disable-ntlm \ --disable-pcre --without-libiconv-prefix --without-libintl-prefix \ --without-libuuid --without-libpsl --without-ssl --without-zlib Mojca
Re: [Bug-wget] Problems with (not) building wget against libiconv
Hi Mojca, On 04/18/2017 04:27 AM, Mojca Miklavec wrote: > On 16 April 2017 at 18:54, Tim Rühsen wrote: >> >> Please make sure, you test with latest wget git. > > I have some problems with bootstrapping. > > On Solaris it's: > >> ./bootstrap > ./bootstrap: syntax error at line 91: `me_=$' unexpected I experience this as well and use 'bash ./bootstrap'. Just pushed a commit to mention this in README.checkout. > On Mac it's: > > sed: 1: "lib/unicase/special-cas ...": extra characters at the end of l > command > ./bootstrap: bootstrap_post_import_hook failed The 'sed' command used in 'bootstrap.conf' seems to be incompatible to GNU sed. Just pushed a commit to make this more portable. Please test and report. > After that the build succeeds, but it's linking against libiconv > (contrary to --without-libiconv-prefix): > >> otool -L wget > wget: > /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 125.2.11) > > On Mac that should be OK (I hope), but on Solaris there is no libiconv > by default. > > I copiled a folder with bootstrapped wget to the Solaris box, but as > expected I ended up with: > >> ldd src/wget > libsocket.so.1 =>/lib/libsocket.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > librt.so.1 =>/lib/librt.so.1 > libiconv.so.2 => /opt/csw/lib/libiconv.so.2 > libunistring.so.2 => /opt/csw/lib/libunistring.so.2 > ... > > And having libraries from /opt/csw there is simply not acceptable > since the binaries won't work on machines without OpenCSW installed. > > So my next question would be: how can I get rid of dependency on libiconv? > > I didn't have this problem in version 1.17.1. I'll have a look into this. Regards, Tim signature.asc Description: OpenPGP digital signature
Re: [Bug-wget] Problems with (not) building wget against libiconv
On 04/18/2017 04:27 AM, Mojca Miklavec wrote:
> I copiled a folder with bootstrapped wget to the Solaris box, but as
> expected I ended up with:
>
>> ldd src/wget
> libsocket.so.1 =>/lib/libsocket.so.1
> libnsl.so.1 => /lib/libnsl.so.1
> librt.so.1 =>/lib/librt.so.1
> libiconv.so.2 => /opt/csw/lib/libiconv.so.2
> libunistring.so.2 => /opt/csw/lib/libunistring.so.2
> ...
>
> And having libraries from /opt/csw there is simply not acceptable
> since the binaries won't work on machines without OpenCSW installed.
>
> So my next question would be: how can I get rid of dependency on libiconv?
>
> I didn't have this problem in version 1.17.1.
>
> Repeating the configure string:
>
> --enable-ipv6 --disable-iri --disable-nls --disable-ntlm \
> --disable-pcre --without-libiconv-prefix --without-libintl-prefix \
> --without-libuuid --without-libpsl --without-ssl --without-zlib
The OpenCSW Solaris box "unstable10x" and likely all others are
configured to use a GNU environment for building. That includes a
separate 'libiconv.so' as well as system headers being loaded from the
GNU environment.
./configure correctly finds and uses the 'iconv.h' and 'libiconv.so'
within the GNU environment. That's not what you want - you basically
want a build on a plain Solaris box so that the 'wget' executable does
not reference any GNU libraries.
Solaris has iconv functionality built into the libc - so there is no
reason for you not to use it. The question is, how you can do do that.
You have to do some manual changes (you could set up a shell script
doing that with 'sed'):
1. Change include of iconv.h in src/url.h:
diff --git a/src/url.c b/src/url.c
index 4aaef63..35b8a49 100644
--- a/src/url.c
+++ b/src/url.c
@@ -44,7 +44,7 @@ as that of the covered work. */
#include "c-strcase.h"
#ifdef HAVE_ICONV
-# include
+# include "/usr/include/iconv.h"
#endif
#include
2. edit src/Makefile.am to remove -liconv and -lunistring (each has two
occurrences)
Now cd into src and 'make clean && make' and your 'wget' executable is
clean:
ldd wget:
libsocket.so.1 =>/lib/libsocket.so.1
libnsl.so.1 => /lib/libnsl.so.1
librt.so.1 =>/lib/librt.so.1
libc.so.1 => /lib/libc.so.1
libmp.so.2 =>/lib/libmp.so.2
libmd.so.1 =>/lib/libmd.so.1
libscf.so.1 => /lib/libscf.so.1
libaio.so.1 => /lib/libaio.so.1
libdoor.so.1 => /lib/libdoor.so.1
libuutil.so.1 => /lib/libuutil.so.1
libgen.so.1 => /lib/libgen.so.1
libm.so.2 => /lib/libm.so.2
Maybe there is an easier way on OpenCSW. If you find out, let us know.
The problem with using the Solaris compiler and/or iconv() is that there
is a known bug in the implementation that ./configure checks for.
If it finds this bug, HAVE_ICONV will not be defined and compilation of
src/url.c then fails.
You can translate the following with 'cc x.c' and execute 'a.out'. The
code is taken from ./configure:
#include
#include
#include
#define ICONV_CONST const
int main(void)
{
int result = 0;
iconv_t cd_ascii_to_88591 = iconv_open ("ISO8859-1", "646");
if (cd_ascii_to_88591 != (iconv_t)(-1))
{
static ICONV_CONST char input[] = "\263";
char buf[10];
ICONV_CONST char *inptr = input;
size_t inbytesleft = strlen (input);
char *outptr = buf;
size_t outbytesleft = sizeof (buf);
size_t res = iconv (cd_ascii_to_88591,
&inptr, &inbytesleft,
&outptr, &outbytesleft);
if (res == 0) {
printf("ouch, bug!\n");
result |= 2;
}
iconv_close (cd_ascii_to_88591);
}
return result;
}
Regards, Tim
signature.asc
Description: OpenPGP digital signature
Re: [Bug-wget] Problems with (not) building wget against libiconv
On 04/18/2017 12:57 PM, Tim Rühsen wrote: > On 04/18/2017 04:27 AM, Mojca Miklavec wrote: >> I copiled a folder with bootstrapped wget to the Solaris box, but as >> expected I ended up with: >> >>> ldd src/wget >> libsocket.so.1 =>/lib/libsocket.so.1 >> libnsl.so.1 => /lib/libnsl.so.1 >> librt.so.1 =>/lib/librt.so.1 >> libiconv.so.2 => /opt/csw/lib/libiconv.so.2 >> libunistring.so.2 => /opt/csw/lib/libunistring.so.2 >> ... >> >> And having libraries from /opt/csw there is simply not acceptable >> since the binaries won't work on machines without OpenCSW installed. >> >> So my next question would be: how can I get rid of dependency on libiconv? >> >> I didn't have this problem in version 1.17.1. >> >> Repeating the configure string: >> >> --enable-ipv6 --disable-iri --disable-nls --disable-ntlm \ >> --disable-pcre --without-libiconv-prefix --without-libintl-prefix \ >> --without-libuuid --without-libpsl --without-ssl --without-zlib > > The OpenCSW Solaris box "unstable10x" and likely all others are > configured to use a GNU environment for building. That includes a > separate 'libiconv.so' as well as system headers being loaded from the > GNU environment. > > ./configure correctly finds and uses the 'iconv.h' and 'libiconv.so' > within the GNU environment. That's not what you want - you basically > want a build on a plain Solaris box so that the 'wget' executable does > not reference any GNU libraries. > > Solaris has iconv functionality built into the libc - so there is no > reason for you not to use it. The question is, how you can do do that. > > You have to do some manual changes (you could set up a shell script > doing that with 'sed'): > > 1. Change include of iconv.h in src/url.h: > > diff --git a/src/url.c b/src/url.c > index 4aaef63..35b8a49 100644 > --- a/src/url.c > +++ b/src/url.c > @@ -44,7 +44,7 @@ as that of the covered work. */ > #include "c-strcase.h" > > #ifdef HAVE_ICONV > -# include > +# include "/usr/include/iconv.h" > #endif > #include > > 2. edit src/Makefile.am to remove -liconv and -lunistring (each has two > occurrences) > > > Now cd into src and 'make clean && make' and your 'wget' executable is > clean: > > ldd wget: > libsocket.so.1 =>/lib/libsocket.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > librt.so.1 =>/lib/librt.so.1 > libc.so.1 => /lib/libc.so.1 > libmp.so.2 =>/lib/libmp.so.2 > libmd.so.1 =>/lib/libmd.so.1 > libscf.so.1 => /lib/libscf.so.1 > libaio.so.1 => /lib/libaio.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > libgen.so.1 => /lib/libgen.so.1 > libm.so.2 => /lib/libm.so.2 > > > Maybe there is an easier way on OpenCSW. If you find out, let us know. > > > The problem with using the Solaris compiler and/or iconv() is that there > is a known bug in the implementation that ./configure checks for. > If it finds this bug, HAVE_ICONV will not be defined and compilation of > src/url.c then fails. Just pushed some commits. That should enable you to $ CC=cc ./configure ... (all your options) to get a clean wget executable (with just Solaris system libraries). Regards, Tim signature.asc Description: OpenPGP digital signature
Re: [Bug-wget] Problems with (not) building wget against libiconv
On 18 April 2017 at 14:43, Tim Rühsen wrote: > On 04/18/2017 12:57 PM, Tim Rühsen wrote: >> On 04/18/2017 04:27 AM, Mojca Miklavec wrote: >>> I copiled a folder with bootstrapped wget to the Solaris box, but as >>> expected I ended up with: >>> ldd src/wget >>> libsocket.so.1 =>/lib/libsocket.so.1 >>> libnsl.so.1 => /lib/libnsl.so.1 >>> librt.so.1 =>/lib/librt.so.1 >>> libiconv.so.2 => /opt/csw/lib/libiconv.so.2 >>> libunistring.so.2 => /opt/csw/lib/libunistring.so.2 >>> ... >>> >>> And having libraries from /opt/csw there is simply not acceptable >>> since the binaries won't work on machines without OpenCSW installed. >>> >>> So my next question would be: how can I get rid of dependency on libiconv? >>> >>> I didn't have this problem in version 1.17.1. >>> >>> Repeating the configure string: >>> >>> --enable-ipv6 --disable-iri --disable-nls --disable-ntlm \ >>> --disable-pcre --without-libiconv-prefix --without-libintl-prefix \ >>> --without-libuuid --without-libpsl --without-ssl --without-zlib >> >> The OpenCSW Solaris box "unstable10x" and likely all others are >> configured to use a GNU environment for building. That includes a >> separate 'libiconv.so' as well as system headers being loaded from the >> GNU environment. >> >> ./configure correctly finds and uses the 'iconv.h' and 'libiconv.so' >> within the GNU environment. That's not what you want - you basically >> want a build on a plain Solaris box so that the 'wget' executable does >> not reference any GNU libraries. >> >> Solaris has iconv functionality built into the libc - so there is no >> reason for you not to use it. The question is, how you can do do that. >> >> You have to do some manual changes (you could set up a shell script >> doing that with 'sed'): >> >> 1. Change include of iconv.h in src/url.h: >> >> diff --git a/src/url.c b/src/url.c >> index 4aaef63..35b8a49 100644 >> --- a/src/url.c >> +++ b/src/url.c >> @@ -44,7 +44,7 @@ as that of the covered work. */ >> #include "c-strcase.h" >> >> #ifdef HAVE_ICONV >> -# include >> +# include "/usr/include/iconv.h" >> #endif >> #include >> >> 2. edit src/Makefile.am to remove -liconv and -lunistring (each has two >> occurrences) >> >> >> Now cd into src and 'make clean && make' and your 'wget' executable is >> clean: >> >> ldd wget: >> libsocket.so.1 =>/lib/libsocket.so.1 >> libnsl.so.1 => /lib/libnsl.so.1 >> librt.so.1 =>/lib/librt.so.1 >> libc.so.1 => /lib/libc.so.1 >> libmp.so.2 =>/lib/libmp.so.2 >> libmd.so.1 =>/lib/libmd.so.1 >> libscf.so.1 => /lib/libscf.so.1 >> libaio.so.1 => /lib/libaio.so.1 >> libdoor.so.1 => /lib/libdoor.so.1 >> libuutil.so.1 => /lib/libuutil.so.1 >> libgen.so.1 => /lib/libgen.so.1 >> libm.so.2 => /lib/libm.so.2 >> >> >> Maybe there is an easier way on OpenCSW. If you find out, let us know. This sounds a bit complex to do (not that it couldn't be done, but ...) >> The problem with using the Solaris compiler and/or iconv() is that there >> is a known bug in the implementation that ./configure checks for. >> If it finds this bug, HAVE_ICONV will not be defined and compilation of >> src/url.c then fails. > > Just pushed some commits. That should enable you to > $ CC=cc ./configure ... (all your options) > > to get a clean wget executable (with just Solaris system libraries). Thank you. This indeed works, but if I try the gcc compiler again, then I get CCLD wget Undefined first referenced symbol in file bindconnect.o recvconnect.o getservbyname ../lib/libgnu.a(getaddrinfo.o) getsockname connect.o accept connect.o listen connect.o gethostbyname ../lib/libgnu.a(getaddrinfo.o) socket connect.o setsockopt connect.o connect connect.o getpeername connect.o inet_ntop host.o gai_strerrorhost.o ld: fatal: symbol referencing errors. No output written to wget and I suspect users on other OSes might experience similar problems. Mojca
Re: [Bug-wget] Problems with (not) building wget against libiconv
On 20 April 2017 at 02:06, Mojca Miklavec wrote: > On 18 April 2017 at 14:43, Tim Rühsen wrote: >> >> Just pushed some commits. That should enable you to >> $ CC=cc ./configure ... (all your options) >> >> to get a clean wget executable (with just Solaris system libraries). > > Thank you. This indeed works, but if I try the gcc compiler again, then I get > > CCLD wget > Undefined first referenced > symbol in file > bindconnect.o > recvconnect.o > getservbyname ../lib/libgnu.a(getaddrinfo.o) > getsockname connect.o > accept connect.o > listen connect.o > gethostbyname ../lib/libgnu.a(getaddrinfo.o) > socket connect.o > setsockopt connect.o > connect connect.o > getpeername connect.o > inet_ntop host.o > gai_strerrorhost.o > ld: fatal: symbol referencing errors. No output written to wget > > and I suspect users on other OSes might experience similar problems. Oh, I'm sorry. This is an older bug that has already been present in the previous version (which is not to say that it shouldn't be fixed :). If I manually add "-lsocket -lnsl" to the last linker command, then it works. Mojca
Re: [Bug-wget] Problems with (not) building wget against libiconv
On 04/18/2017 02:32 PM, Tim Rühsen wrote: I have some problems with bootstrapping. On Solaris it's: ./bootstrap ./bootstrap: syntax error at line 91: `me_=$' unexpected I experience this as well and use 'bash ./bootstrap'. Autoconf manual says $(...) style command substitution is less portable than using backticks `...`. https://www.gnu.org/software/autoconf/manual/autoconf.html#Shell-Substitutions Hope it helps. I am unable to do any testing at the moment, so sorry. Regards, Akash Rawal
Re: [Bug-wget] Problems with (not) building wget against libiconv
On 04/20/2017 02:25 PM, Akash Rawal wrote: > > > On 04/18/2017 02:32 PM, Tim Rühsen wrote: >>> I have some problems with bootstrapping. >>> >>> On Solaris it's: >>> ./bootstrap >>> ./bootstrap: syntax error at line 91: `me_=$' unexpected >> >> I experience this as well and use 'bash ./bootstrap'. > Autoconf manual says $(...) style command substitution is less portable > than using backticks `...`. > https://www.gnu.org/software/autoconf/manual/autoconf.html#Shell-Substitutions 'bootstrap' is a gnulib script. We are just using it. I wouldn't bother with it, but if you do - contact the gnulib mailing list for information/help/clarification. Any improvements will flow into all projects using this script. Regards, Tim signature.asc Description: OpenPGP digital signature
Re: [Bug-wget] Problems with (not) building wget against libiconv
On 04/20/2017 02:15 AM, Mojca Miklavec wrote: > On 20 April 2017 at 02:06, Mojca Miklavec wrote: >> On 18 April 2017 at 14:43, Tim Rühsen wrote: >>> >>> Just pushed some commits. That should enable you to >>> $ CC=cc ./configure ... (all your options) >>> >>> to get a clean wget executable (with just Solaris system libraries). >> >> Thank you. This indeed works, but if I try the gcc compiler again, then I get >> >> CCLD wget >> Undefined first referenced >> symbol in file >> bindconnect.o >> recvconnect.o >> getservbyname ../lib/libgnu.a(getaddrinfo.o) >> getsockname connect.o >> accept connect.o >> listen connect.o >> gethostbyname ../lib/libgnu.a(getaddrinfo.o) >> socket connect.o >> setsockopt connect.o >> connect connect.o >> getpeername connect.o >> inet_ntop host.o >> gai_strerrorhost.o >> ld: fatal: symbol referencing errors. No output written to wget >> >> and I suspect users on other OSes might experience similar problems. > > Oh, I'm sorry. This is an older bug that has already been present in > the previous version (which is not to say that it shouldn't be fixed > :). Can't reproduce on OpenCSW unstable10x (and never saw this before). Btw, I switched sucessfully back to gcc with CC=gcc ./configure --enable-ipv6 --disable-iri --disable-nls --disable-ntlm --disable-pcre --without-libiconv-prefix --without-libintl-prefix --without-libuuid --without-libpsl --without-ssl --without-zlib --without-metalink && make clean && make Regards, Tim signature.asc Description: OpenPGP digital signature
