Re: Bug in gls (coreutils)

2013-01-28 Thread Stefan Sperling
On Mon, Jan 28, 2013 at 02:54:48PM +, Stuart Henderson wrote:
> Which versions of gettext and libiconv are installed?

gettext-0.18.1p5
libiconv-1.14p0

My amd64 system is not quite -current (from Jan 21) so this might
already be fixed.

> Output from setting LD_DEBUG=1 might give some additional clues..

$ env LD_DEBUG=1 LANG=en_US.UTF-8 gls -l
rtld loading: 'gls'
exe load offset:  0xfc035d0
 flags gls = 0x0
head gls
obj gls has gls as head
examining: 'gls'
loading: libc.so.66.1 required by gls
 flags /usr/lib/libc.so.66.1 = 0x0
obj /usr/lib/libc.so.66.1 has gls as head
loading: /usr/local/lib/libintl.so.6.0 required by gls
 flags /usr/local/lib/libintl.so.6.0 = 0x0
obj /usr/local/lib/libintl.so.6.0 has gls as head
linking dep /usr/local/lib/libintl.so.6.0 as child of gls
linking dep /usr/lib/libc.so.66.1 as child of gls
examining: '/usr/local/lib/libintl.so.6.0'
examining: '/usr/lib/libc.so.66.1'
 flags /usr/libexec/ld.so = 0x0
obj /usr/libexec/ld.so has gls as head
relocation took 0.000174
StartEnd  Type Open Ref GrpRef Name
0fc035d0 0fc036127000 exe  10   0  gls
0fc2377c3000 0fc237bcd000 rlib 01   0  
/usr/local/lib/libintl.so.6.0
0fc23e1e5000 0fc23e6cd000 rlib 01   0  
/usr/lib/libc.so.66.1
0fc23d30 0fc23d30 rtld 01   0  
/usr/libexec/ld.so
symcache lookups 228 hits 39 ratio 17% hits
dynamic loading done, success.
doing ctors obj 0xfc23d643838 @0xfc2377c4e30: [/usr/local/lib/libintl.so.6.0]
doing ctors obj 0xfc23d6434d0 @0xfc23e204880: [/usr/lib/libc.so.66.1]
entry point: 0xfc035d041d0
gls:/usr/local/lib/libintl.so.6.0: undefined symbol 
'libiconv_set_relocation_prefix'
lazy binding failed!
Segmentation fault (core dumped) 



Re: Bug in gls (coreutils)

2013-01-28 Thread Stuart Henderson
On 2013/01/28 15:42, Stefan Sperling wrote:
> On Mon, Jan 28, 2013 at 02:34:56PM +, Stuart Henderson wrote:
> > On 2013/01/28 15:13, Lars Engblom wrote:
> > > export LANG=en_US.UTF-8
> > > gls -l
> > > 
> > > This will dump a core on both current and stable.
> > > 
> > > Regards,
> > >  Lasse
> > > 
> > 
> > Works for me on amd64. Do you have a backtrace, ideally from a copy
> > built with DEBUG=-g? Does it need some special file in the directory?
> 
> Seems to be a missing library bump or something:
> 
> $ export LANG=en_US.UTF-8
> $ gls -l
> gls:/usr/local/lib/libintl.so.6.0: undefined symbol 
> 'libiconv_set_relocation_prefix'
> lazy binding failed!
> Segmentation fault (core dumped) 
> 

Which versions of gettext and libiconv are installed?
Output from setting LD_DEBUG=1 might give some additional clues..

libiconv didn't change in a while; gettext was updated recently but
gls is working for me with gettext-0.18.2 - (also this wouldn't have
affected -stable for the OP).



Re: Bug in gls (coreutils)

2013-01-28 Thread Lars Engblom



Here is a more full error report:

_=/usr/bin/env
LOGNAME=lasse
WINDOWID=6291490
WINDOWPATH=5
XTERM_SHELL=/bin/ksh
HOME=/home/lasse
PKG_PATH=ftp://ftp.eu.openbsd.org/pub/OpenBSD/5.2/packages/amd64/
CVSROOT=anon...@anoncvs1.ca.openbsd.org:/cvs
LC_CTYPE=en_US.UTF-8
XTERM_VERSION=XTerm/OpenBSD(279)
DISPLAY=:0
LANG=en_US.UTF-8
ENV=/home/lasse/.kshrc
PATH=/home/lasse/bin:/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/sbin:/usr/games:.:/usr/local/racket/bin:/usr/local/sbin
HISTFILE=/home/lasse/.history
PS1=\e[1;32m\h \e[1;34m\W $ \e[0m
TERM=xterm-color
SHELL=/bin/ksh
USER=lasse
XTERM_LOCALE=en_US.UTF-8


gls -l
gls:/usr/local/lib/libintl.so.6.0: undefined symbol
'libiconv_set_relocation_prefix'
lazy binding failed!
Segmentation fault (core dumped)

This is on OpenBSD 5.2 (amd64) with coreutils installed from offical
ftp. I will try to get a backtrace, once I get to another computer.


On 01/28/13 16:34, Stuart Henderson wrote:

On 2013/01/28 15:13, Lars Engblom wrote:

export LANG=en_US.UTF-8
gls -l

This will dump a core on both current and stable.

Regards,
  Lasse


Works for me on amd64. Do you have a backtrace, ideally from a copy
built with DEBUG=-g? Does it need some special file in the directory?









Re: Bug in gls (coreutils)

2013-01-28 Thread Stefan Sperling
On Mon, Jan 28, 2013 at 02:34:56PM +, Stuart Henderson wrote:
> On 2013/01/28 15:13, Lars Engblom wrote:
> > export LANG=en_US.UTF-8
> > gls -l
> > 
> > This will dump a core on both current and stable.
> > 
> > Regards,
> >  Lasse
> > 
> 
> Works for me on amd64. Do you have a backtrace, ideally from a copy
> built with DEBUG=-g? Does it need some special file in the directory?

Seems to be a missing library bump or something:

$ export LANG=en_US.UTF-8
$ gls -l
gls:/usr/local/lib/libintl.so.6.0: undefined symbol 
'libiconv_set_relocation_prefix'
lazy binding failed!
Segmentation fault (core dumped) 



Re: Bug in gls (coreutils)

2013-01-28 Thread Stuart Henderson
On 2013/01/28 15:13, Lars Engblom wrote:
> export LANG=en_US.UTF-8
> gls -l
> 
> This will dump a core on both current and stable.
> 
> Regards,
>  Lasse
> 

Works for me on amd64. Do you have a backtrace, ideally from a copy
built with DEBUG=-g? Does it need some special file in the directory?



Bug in gls (coreutils)

2013-01-28 Thread Lars Engblom

export LANG=en_US.UTF-8
gls -l

This will dump a core on both current and stable.

Regards,
 Lasse