Re: Problems with iconv in base and static linking
On Wed, 21 Aug 2013 21:49+0200, Dimitry Andric wrote:
Hi,
While packaging my just-rebuilt ports today, I noticed a strange message
occurring during the package creation stage:
$ sudo make -C /usr/ports/ports-mgmt/pkg repackage
=== Building package for pkg-1.1.4_1
Creating package for pkg-1.1.4_1
Service unavailable
I'd just like to voice my opinion over the mostly meaningless error
message. It's an insult to us users, and us system administrators in
particular. Please do better by providing error messages that
adequately explains what went wrong. Now that's an idea for GSoC. ;-)
$
In fact, *every* make package/repackage produces the Service
unavailable message. The message is actually produced by the pkg(8)
command, which is run as follows:
/usr/local/sbin/pkg-static create -o /usr/ports/packages pkg-1.1.4_1
Now comes the interesting part: if you use /usr/local/sbin/pkg instead,
the Service unavailable message does *not* appear.
It turns out this is because pkg(8) uses libarchive, which is now
compiled with iconv support from base by default. But the iconv in base
does *not* work properly in statically linked executables. For example,
take this small program:
#include err.h
#include iconv.h
int main(void)
{
iconv_t ic = iconv_open(UTF-8, ISO-8859-1);
if (ic == (iconv_t)-1)
err(1, iconv_open failed);
iconv_close(ic);
return 0;
}
If you compile and link this statically, it will produce:
$ cc -static iconv-test.c -o iconv-test-static
$ ./iconv-test-static
iconv-test-static: iconv_open failed: Invalid argument
Service unavailable$
The reason for the message is that libc's iconv tries to dlopen(3) a
dynamic library in /usr/lib/i18n, which does not work in static
executables.
As a quick fix for pkg(8), we could build the static version of
libarchive without -DHAVE_ICONV and friends. This also helps other
consumers of libarchive that link statically.
Of course, there may be other consumers of libc's iconv that might want
to link statically, so it should really be fixed there instead. For
example, by not doing the dlopen, and failing gracefully. Or maybe by
actually linking in (a subset of) the /usr/lib/i18n libraries.
-Dimitry
--
+---++
| Vennlig hilsen, | Best regards, |
| Trond Endrestøl, | Trond Endrestøl, |
| IT-ansvarlig, | System administrator, |
| Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
| tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
| sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. |
+---++___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problems with iconv in base and static linking
On 8/21/2013 2:49 PM, Dimitry Andric wrote: Hi, While packaging my just-rebuilt ports today, I noticed a strange message occurring during the package creation stage: $ sudo make -C /usr/ports/ports-mgmt/pkg repackage === Building package for pkg-1.1.4_1 Creating package for pkg-1.1.4_1 Service unavailable$ In fact, *every* make package/repackage produces the Service unavailable message. The message is actually produced by the pkg(8) command, which is run as follows: /usr/local/sbin/pkg-static create -o /usr/ports/packages pkg-1.1.4_1 Now comes the interesting part: if you use /usr/local/sbin/pkg instead, the Service unavailable message does *not* appear. It turns out this is because pkg(8) uses libarchive, which is now compiled with iconv support from base by default. But the iconv in base does *not* work properly in statically linked executables. For example, take this small program: ... Of course, there may be other consumers of libc's iconv that might want to link statically, so it should really be fixed there instead. For example, by not doing the dlopen, and failing gracefully. Or maybe by actually linking in (a subset of) the /usr/lib/i18n libraries. -Dimitry I agree this is an iconv issue and that should be fixed instead of bandaging consumers as they are found. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Problems with iconv in base and static linking
Hi,
While packaging my just-rebuilt ports today, I noticed a strange message
occurring during the package creation stage:
$ sudo make -C /usr/ports/ports-mgmt/pkg repackage
=== Building package for pkg-1.1.4_1
Creating package for pkg-1.1.4_1
Service unavailable$
In fact, *every* make package/repackage produces the Service
unavailable message. The message is actually produced by the pkg(8)
command, which is run as follows:
/usr/local/sbin/pkg-static create -o /usr/ports/packages pkg-1.1.4_1
Now comes the interesting part: if you use /usr/local/sbin/pkg instead,
the Service unavailable message does *not* appear.
It turns out this is because pkg(8) uses libarchive, which is now
compiled with iconv support from base by default. But the iconv in base
does *not* work properly in statically linked executables. For example,
take this small program:
#include err.h
#include iconv.h
int main(void)
{
iconv_t ic = iconv_open(UTF-8, ISO-8859-1);
if (ic == (iconv_t)-1)
err(1, iconv_open failed);
iconv_close(ic);
return 0;
}
If you compile and link this statically, it will produce:
$ cc -static iconv-test.c -o iconv-test-static
$ ./iconv-test-static
iconv-test-static: iconv_open failed: Invalid argument
Service unavailable$
The reason for the message is that libc's iconv tries to dlopen(3) a
dynamic library in /usr/lib/i18n, which does not work in static
executables.
As a quick fix for pkg(8), we could build the static version of
libarchive without -DHAVE_ICONV and friends. This also helps other
consumers of libarchive that link statically.
Of course, there may be other consumers of libc's iconv that might want
to link statically, so it should really be fixed there instead. For
example, by not doing the dlopen, and failing gracefully. Or maybe by
actually linking in (a subset of) the /usr/lib/i18n libraries.
-Dimitry
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
