[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libidn 1.22: sed commands on Solaris 11 too long

From: Simon Josefsson
Subject: Re: libidn 1.22: sed commands on Solaris 11 too long
Date: Thu, 11 Aug 2011 09:00:54 +0200
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux)

Thanks for the report Mark.  The problem is in gnulib, so I'm cc'ing the
bug-gnulib list for assistance.

It seems SunOS 5.11 /bin/sed cannot handle the gnulib sed -e construct
to create replacement header files.  I recall some discussion about too
many -e parameters for some sed, but I'm not sure what the conclusion
was?  It seems for example modules/unistd already split up the sed -e
rules into several pipe:d sed invocations but maybe it has grown too
large?  What is the precise limit?  Number of -e's or size of command
line?  Maybe we can just try to split it further and see if it helps.

Mark, would you be able to test a snapshot release if I make one?


Mark Ashley <address@hidden> writes:

> Hey folks,
> I'm compiling up libidn on a variety of Solaris revs at the moment.
> This is my recipe:
> CC=cc
> LD_RUN_PATH=/usr/local/lib:/lib:/usr/lib
>     cd /var/tmp
>     rm -rf /libidn libidn-1.22
>     untgz /usr/local/src/gnu/libidn-1.22.tar.gz
>     cd libidn-1.22
>     mkdir /libidn
>     ./configure --prefix=/libidn \
>                 --with-libiconv-prefix=/usr/local \
>                 --with-libintl-prefix=/usr/local
>     gmake LDFLAGS=-L/usr/local/lib LIBS=-lintl
> The problem I'm seeing on my "SunOS lap 5.11 snv_134 i86pc i386 i86pc"
> machine is the sed commands used in the are too long and
> the sed is freezing up.
> This happens for the gl/ rule, the
> lib/gltests/ rule and the
> lib/gltests/ rule.
> If I manually edit the long "sed -e" commands and halve each of them
> into separate smaller "sed -e" commands similarly piped into the next
> one, the same as the original Makefile code then the sed stream works
> normally and the make continues to compile the libidn library
> successfully. The OS shipped sed isn't happy with the length of the
> "-e" commands it's asked to do. I've seen this behaviour on the three
> rules mentioned above, but it'd be nice to preemptively shorted the
> long sed commands in all the Makefiles to avoid this in the future.
> This problem doesn't occur on Solaris 10 x86 or SPARC. All the
> machines are using the vendor shipped /bin/sed.
> Thanks
> Mark
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]