Ports Issue with 20130316: libiconv & gettext

Hey folks,

I'm having trouble on 9.1-RELEASE with the following UPDATING directions:

Code:
  # pkg delete -f devel/gettext
  # portmaster converters/libiconv devel/gettext

It seems that removal of devel/gettext hoses something which does not allow me to follow the directions.

I get
Code:
Shared object "libintl.so.9" not found, required by "sed"
during the portmaster parts (full log here): http://pastebin.com/gfFayaXz

Short failure message here:
Code:
/bin/sh /usr/local/bin/libtool --mode=compile --tag=CC cc -I. -I. -I.. -I./.. -I../include -O2 -pipe -fno-strict-aliasing  -DLIBDIR=\"/usr/local/lib\" -DBUILDING_LIBCHARSET -DBUILDING_DLL  -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/local/lib\" -DNO_XMALLOC  -Dset_relocation_prefix=libcharset_set_relocation_prefix  -Drelocate=libcharset_relocate -DHAVE_CONFIG_H -c ./localcharset.c
Shared object "libintl.so.9" not found, required by "sed"
Shared object "libintl.so.9" not found, required by "sed"
Shared object "libintl.so.9" not found, required by "sed"
libtool: compile: Failed to create `.libs'
*** [localcharset.lo] Error code 1

I am running /bin/csh for root's shell. What am I doing wrong?
 
Did you install japanese/sed? The base sed(1) isn't linked to libintl.
Code:
root@j-build-server:/usr/ports# ldd /usr/bin/sed
/usr/bin/sed:
        libc.so.7 => /lib/libc.so.7 (0x800822000)
 
Code:
Shared object "libintl.so.9" not found, required by "sed"

That suggests it is trying to use textproc/gsed rather than FreeBSD's sed(1). I'm not sure why that port is using NLS, unless you have that enabled in make.conf. Rebuilding just textproc/gsed with -DWITHOUT_NLS may work.

In any case, the devel/gettext maintainer should be notified about the recursive problem of gsed built with NLS failing after gettext is deinstalled, and then being required to install gettext. If the gettext install could use FreeBSD's sed, that would avoid the problem.
 
wblock@ said:
Code:
Shared object "libintl.so.9" not found, required by "sed"

That suggests it is trying to use textproc/gsed rather than FreeBSD's sed(1). I'm not sure why that port is using NLS, unless you have that enabled in make.conf. Rebuilding just textproc/gsed with -DWITHOUT_NLS may work.

In any case, the devel/gettext maintainer should be notified about the recursive problem of gsed built with NLS failing after gettext is deinstalled, and then being required to install gettext. If the gettext install could use FreeBSD's sed, that would avoid the problem.

That makes sense, I use gsed (and gawk) because I'm a mutt/notmuch user and some of the glue requires GNU versions. I do not have NLS or anything special in make.conf other than to use PKGNG and specify my Perl version:

Code:
WITH_PKGNG=yes
PERL_VERSION=5.14.2

Could I also just temporarily remove gawk/gsed (findutils/coreutils iirc) and then try?

Thank you for the response.
 
gsed is a separate port, textproc/gsed. Port stuff should have specific paths to utilities, but I don't know if that's the case with gsed. Either way, gsed probably doesn't work now anyway, so removing it won't make things any worse. Check root's path first, making sure /usr/bin is before /usr/local/bin.
 
wblock@ said:
gsed is a separate port, textproc/gsed. Port stuff should have specific paths to utilities, but I don't know if that's the case with gsed. Either way, gsed probably doesn't work now anyway, so removing it won't make things any worse. Check root's path first, making sure /usr/bin is before /usr/local/bin.

Path looks ok:
Code:
# echo $PATH
/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin

Looks like awk is just awk:
Code:
# which awk
/usr/bin/awk

Try #2: Removing gsed/gawk first (same thing)
Code:
===>  Building for libiconv-1.14_1
builddir="`pwd`"; cd libcharset && /usr/bin/make all && /usr/bin/make install-lib libdir="$builddir/lib" includedir="$builddir/lib"
if [ ! -d include ] ; then mkdir include ; fi
cp ./include/libcharset.h.in include/libcharset.h
cd lib && /usr/bin/make all
/bin/sh /usr/local/bin/libtool --mode=compile --tag=CC cc -I. -I. -I.. -I./.. -I../include -O2 -pipe -fno-strict-aliasing  -DLIBDIR=\"/usr/local/lib\" -DBUILDING_LIBCHARSET -DBUILDING_DLL  -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/local/lib\" -DNO_XMALLOC  -Dset_relocation_prefix=libcharset_set_relocation_prefix  -Drelocate=libcharset_relocate -DHAVE_CONFIG_H -c ./localcharset.c
Shared object "libintl.so.9" not found, required by "sed"

Rolling back the ZFS snapshot and I'll keep digging. Is it still possible NLS is the culprit with awk or other libraries?
 
SirDice said:
Did you install japanese/sed? The base sed(1) isn't linked to libintl.
Code:
root@j-build-server:/usr/ports# ldd /usr/bin/sed
/usr/bin/sed:
        libc.so.7 => /lib/libc.so.7 (0x800822000)

Code:
It appears my sed is normal
# ldd /usr/bin/sed
/usr/bin/sed:
	libc.so.7 => /lib/libc.so.7 (0x800821000)

Code:
/usr/ports/japanese/sed
# make deinstall
===>  Deinstalling for japanese/sed
===>   ja-sed not installed, skipping
 
If it matters, I'm doing all of this via a sudo su - xterm as root (with csh). When gettext gets removed it seems to take libintl.so.9 with it and libtool wants that present or else libiconv build fails per the sed errors above.

Code:
# pkg which "/usr/local/lib/libintl.so.9"
/usr/local/lib/libintl.so.9 was installed by package gettext-0.18.1.1

Considering there aren't more than a few threads about this, I imagine I must be doing something wrong or have some kind of library/build conflict or my PKGNG is angry.
 
sadsfae said:
If it matters, I'm doing all of this via a sudo su - xterm
as root (with csh). When gettext gets removed it seems to take libintl.so.9 with it and libtool wants that present or else libiconv build fails per the sed errors above.

Code:
# pkg which "/usr/local/lib/libintl.so.9"
/usr/local/lib/libintl.so.9 was installed by package gettext-0.18.1.1

Considering there aren't more than a few threads about this, I imagine I must be doing something wrong or have some kind of library/build conflict or my pkgng is angry.

Ok, doing the build via ssh root@ makes no difference (thinking in some way sudo is why it was breaking). Would it work if copied /usr/local/lib/libintl.so.9 somewhere like /tmp/ and copied it back after I removed devel/gettext so converters/libiconv could perhaps build but before I rebuilt devel/gettext with portmaster?
 
Wait, the error is in converters/libiconv, I was thinking it was in devel/gettext.

Don't use portmaster or any other external tool, just [cmd=1]make[/cmd].
Code:
# script /tmp/libiconv.log
# cd /usr/ports/converters/libiconv
# make clean
# make -V SED
# make
# exit

Post that log file to pastebin.com or anywhere else that's convenient.
 
wblock@ said:
Wait, the error is in converters/libiconv, I was thinking it was in devel/gettext.

Don't use portmaster or any other external tool, just [cmd=1]make[/cmd].
Code:
# script /tmp/libiconv.log
# cd /usr/ports/converters/libiconv
# make clean
# make -V SED
# make
# exit

Post that log file to pastebin.com or anywhere else that's convenient.

Hey wblock, the paste is located here:
http://pastebin.com/w2H21DRJ

The only config option I had in # make config was
Code:
[x] Encodings: Include extra character sets
 
That log shows it builds okay, so the sed(1) error must be during install.
Code:
checking for a sed that does not truncate output... /usr/local/bin/sed

It's worth renaming /usr/local/bin/sed to see if it will give up and use the system sed(1). Beyond that, and maybe deinstalling textproc/gsed, I don't know what else to suggest.
 
As an update, I got libiconv to finally build by keeping the old /usr/local/lib/libintl.so.9 around after removing devel/gettext (which provided it). Seems there were circular dependencies at play.

The following fixed this for me:

Code:
# cp /usr/local/lib/libintl.so.9 /usr/local/lib/libintl.so.9.new
# pkg delete -f devel/gettext
# cp /usr/local/lib/libintl.so.9.new /usr/local/lib/libintl.so.9
# portmaster converters/libiconv devel/gettext

How should I report this upstream if applicable? Seems like a very dirty hack :)
 
Mods, can we please change the topic to "Resolved" so others can use the workaround?
Thank you.
 
Back
Top