[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-wget] Problems with (not) building wget against libiconv
From: |
Tim Rühsen |
Subject: |
Re: [Bug-wget] Problems with (not) building wget against libiconv |
Date: |
Tue, 18 Apr 2017 12:57:37 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
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 <iconv.h>
+# include "/usr/include/iconv.h"
#endif
#include <langinfo.h>
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 <stdio.h>
#include <iconv.h>
#include <string.h>
#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, (continued)
- Re: [Bug-wget] Problems with (not) building wget against libiconv, Tim Rühsen, 2017/04/15
- Re: [Bug-wget] Problems with (not) building wget against libiconv, Mojca Miklavec, 2017/04/15
- Re: [Bug-wget] Problems with (not) building wget against libiconv, Tim Rühsen, 2017/04/16
- Re: [Bug-wget] Problems with (not) building wget against libiconv, Mojca Miklavec, 2017/04/16
- Re: [Bug-wget] Problems with (not) building wget against libiconv, Tim Rühsen, 2017/04/16
- Re: [Bug-wget] Problems with (not) building wget against libiconv, Tim Rühsen, 2017/04/16
- Re: [Bug-wget] Problems with (not) building wget against libiconv, Mojca Miklavec, 2017/04/17
- Re: [Bug-wget] Problems with (not) building wget against libiconv, Tim Rühsen, 2017/04/18
- Re: [Bug-wget] Problems with (not) building wget against libiconv, Akash Rawal, 2017/04/20
- Re: [Bug-wget] Problems with (not) building wget against libiconv, Tim Rühsen, 2017/04/20
- Re: [Bug-wget] Problems with (not) building wget against libiconv,
Tim Rühsen <=
- Re: [Bug-wget] Problems with (not) building wget against libiconv, Tim Rühsen, 2017/04/18
- Re: [Bug-wget] Problems with (not) building wget against libiconv, Mojca Miklavec, 2017/04/19
- Re: [Bug-wget] Problems with (not) building wget against libiconv, Mojca Miklavec, 2017/04/19
- Re: [Bug-wget] Problems with (not) building wget against libiconv, Tim Rühsen, 2017/04/20