bug-coreutils
[Top][All Lists]
Advanced

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

Re: no feedback on snapshot? coreutils-7.5 coming soon


From: Jim Meyering
Subject: Re: no feedback on snapshot? coreutils-7.5 coming soon
Date: Fri, 14 Aug 2009 18:37:59 +0200

Eric Blake wrote:
> Jim Meyering <jim <at> meyering.net> writes:
>> AFAIK, I am the only one who has built the latest snapshot:
>>
>>     http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/17604
>>
>> Though it's been only two days.
>>
>> Unless I hear of new bug reports or portability problems soon,
>> expect coreutils-7.5 to be released in the next few days.
>
> On cygwin, 'make' completes, but 'make check' issues a warning (and fails if I
> also add -Werror to CFLAGS):
>
> ccache gcc -std=gnu99   -gdwarf-2 -Wall -Werror  -Wl,--as-needed -o stdbuf.exe
> stdbuf.o libver.a ../lib/libcoreutils.a /usr/local/lib/libintl.dll.a -liconv -
> L/usr/local/lib ../lib/libcoreutils.a -liconv
> diff progs-makefile progs-readme && rm -rf progs-readme progs-makefile
> ccache gcc -std=gnu99  -I. -I../lib  -I../lib -I/usr/local/include -fPIC   -
> gdwarf-2 -Wall -Werror -MT libstdbuf_so-libstdbuf.o -MD -MP -
> MF .deps/libstdbuf_so-libstdbuf.Tpo -c -o libstdbuf_so-libstdbuf.o `test -
> f 'libstdbuf.c' || echo './'`libstdbuf.c
> libstdbuf.c:1: warning: -fPIC ignored for target (all code is position
> independent)
>
> And even if I don't turn on -Werror, 'make check' dies further on:
>
>   CCLD   libstdbuf.so.exe
> libstdbuf_so-libstdbuf.o: In function `apply_mode':
> /home/eblake/coreutils/src/libstdbuf.c:108: undefined reference to
> `_libintl_gettext'
> /home/eblake/coreutils/src/libstdbuf.c:116: undefined reference to
> `_libintl_gettext'
> /home/eblake/coreutils/src/libstdbuf.c:124: undefined reference to
> `_libintl_gettext'
>
> (wow - it really seems like this should be creating libstdbuf.dll or even
> cygstdbuf.dll, per cygwin naming conventions; not libstdbuf.so.exe).
>
> I'm not sure whether libstdbuf will even work for cygwin (as it is not ELF);

Thanks for the feedback!

In that case, the configure-time check for is-an-ELF-system
must be failing on cygwin:

    # Limit stdbuf to ELF systems with GCC
    optional_pkglib_progs=
    AC_MSG_CHECKING([whether this is an ELF system])
    AC_EGREP_CPP([yes], [#if __ELF__
    yes
    #endif], [elf_sys=yes], [elf_sys=no])
    AC_MSG_RESULT([$elf_sys])
    if test "$elf_sys" = "yes" && \
       test "$GCC" = "yes"; then
      gl_ADD_PROG([optional_bin_progs], [stdbuf])
      gl_ADD_PROG([optional_pkglib_progs], [libstdbuf.so])
    fi

> and part of me is afraid that we would have to use libtool to get this to work

Right.  we want to avoid that.

> portably.  Maybe it is easiest to just figure out how to disable stdbuf from
> even being attempted, let along tested, on cygwin, until I can find more time
> to investigate it further?
>
> I'm now running 'make -k check', and will try to spot any obvious problems.  I
> already have some effort for porting things like freopen O_BINARY issues over
> to cygwin that I have not yet pushed upstream.  But I maintain my stance that,
> as in the past, I don't want you to feel obligated to hold up the release
> process just to cater to cygwin.

Thanks.




reply via email to

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