-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 2/28/2007 4:37 PM:
> The two modules 'utimens' and 'utimecmp' still fail to build even on glibc
> systems, according to http://autobuild.josefsson.org/gnulib/.
>
> Here's a proposed fix:
>
>
> 2007-02-28 Bruno Haible <
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Matthew Woehlke on 2/28/2007 5:46 PM:
> Sigh. Now you're picking up coreutils' problem, trying to use 'unsigned
> long long' on a platform (Tandem NSK/OSS) that "doesn't" have such a
> thing, just because 'long long' exists. 16 errors tryi
FYI, I solved this problem by letting gnulib put GNUmakefile and
maint.mk into build-aux/, and use this top-level GNUmakefile:
have-gnulib-files := $(shell test -f gnulib.mk && test -f maint.mk && echo yes)
ifneq ($(have-gnulib-files),yes)
gnulib.mk:
ln -s build-aux/GNUmakefile gnulib.mk |
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Simon Josefsson on 3/1/2007 6:35 AM:
> FYI, I solved this problem by letting gnulib put GNUmakefile and
> maint.mk into build-aux/, and use this top-level GNUmakefile:
>
> have-gnulib-files := $(shell test -f gnulib.mk && test -f maint.mk
Bruno Haible <[EMAIL PROTECTED]> writes:
> For reference, here are the changes that I did, compared to your patch.
Looks good.
> There is still one problem: The comment at the head of gl_RELOCATABLE
> says that it accepts an argument. But the macro uses always $gl_source_base,
> not $1.
Oops.
Eric Blake wrote:
According to Matthew Woehlke on 2/28/2007 5:46 PM:
Sigh. Now you're picking up coreutils' problem, trying to use 'unsigned
long long' on a platform (Tandem NSK/OSS) that "doesn't" have such a
thing, just because 'long long' exists. 16 errors trying to build printf.c.
That's b
Matthew Woehlke wrote:
Eric Blake wrote:
According to Matthew Woehlke on 2/28/2007 5:46 PM:
Sigh. Now you're picking up coreutils' problem, trying to use 'unsigned
long long' on a platform (Tandem NSK/OSS) that "doesn't" have such a
thing, just because 'long long' exists. 16 errors trying to bu
Bruno Haible <[EMAIL PROTECTED]> writes:
> Therefore I propose to remove this paragraph:
>
> -You should include Gnulib-provided headers before system headers,
> -so that Gnulib-provided headers can adjust how a system header
> -behaves.
That sounds good; thanks.
> The timegm.m4 did check whethe
Yesterday, Nelson Beebe tested coreutils-6.8+.
I replied:
> "Nelson H. F. Beebe" <[EMAIL PROTECTED]> wrote:
> ...
> > I have a question, however. Since 6.8 got installed, I've been
> > seeing a + at the end of the permission field, e.g., on abajo:
> >
> > % ls -l /usr/local/share/man/man3cw/urcw4
Paul Eggert wrote:
> > Therefore I propose to remove this paragraph:
> >
> > -You should include Gnulib-provided headers before system headers,
> > -so that Gnulib-provided headers can adjust how a system header
> > -behaves.
>
> That sounds good; thanks.
OK, I removed it and expanded a bit more
Ralf Wildenhues wrote:
> > Indeed, it would have to be documented in the user's documentation that
> > the relocatable module doesn't work on OpenBSD when shared libraries are
> > involved.
>
> Well. On systems where Libtool hardcodes an absolute soname. 1.5.22
> does it, and 1.5.24 will do it,
install-reloc has a few long lines. I'm breaking them so it's easier to
understand.
2007-03-01 Bruno Haible <[EMAIL PROTECTED]>
* build-aux/install-reloc: Break long lines.
*** build-aux/install-reloc 1 Mar 2007 02:14:04 - 1.2
--- build-aux/install-reloc 2 Mar 2007 01
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Matthew Woehlke on 3/1/2007 9:16 AM:
> Well... aside from the fact that I forgot that (it's been quite a
> while), I still think that if printf.c is going to *assume* unsigned if
> long long exists, then config.h really ought to make this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Matthew Woehlke on 3/1/2007 9:44 AM:
>
> ...it also seems to break tempname.c:
>
> source='tempname.c' object='tempname.o' libtool=no \
> DEPDIR=.deps depmode=none /bin/sh ../depcomp \
> cc -I. -O -c tempname.c
>
Ralf Wildenhues wrote:
> I tried some compilers now. All those I tried coped well with multiple
> source files listed. But just as well, none except GCC are intelligent
> enough by themselves to not stomp upon each others' object files, and
> most do not clean up.
>
> compiler create
Ralf Wildenhues wrote:
> > >> The issue is foo_CFLAGS and foo_LDFLAGS need to refer back to the
> > >> directory in which foo is installed. Thus, if foo is in
> > >> bin_PROGRAMS then the following is correct:
> > >>
> > >> foo_CFLAGS = -DINSTALLDIR=\"$(bindir)\"
>
> FWIW, foo_CPPFLAGS wou
Eric Blake wrote:
> According to Matthew Woehlke on 3/1/2007 9:44 AM:
> >
> > ...it also seems to break tempname.c:
> >
> > source='tempname.c' object='tempname.o' libtool=no \
> > DEPDIR=.deps depmode=none /bin/sh ../depcomp \
> > cc -I. -O -c tempname.c
> > int64_t
Albert Chin wrote:
> > + hpux9* | hpux10* | hpux11*)
> > +shlibpath_var=SHLIB_PATH
> > +;;
>
> HP-UX/IA is ELF so you should really use LD_LIBRARY_PATH.
Oh, right. config.libpath was last updated for libtool 1.5.2. I'm updating it
for libtool-1.5.22:
2007-03-01 Bruno Haible <[EMAIL PR
Albert Chin wrote:
> And, if $compile_command can be libtool, you'll definitely run into
> problems, especially on AIX with -export-dynamic.
This is a non-issue: $compile_command comes from $RELOC_COMPILE_COMMAND, which
is set (in m4/relocatable.m4) to "$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS)" -
th
Bruno Haible <[EMAIL PROTECTED]> writes:
> -system library paths for security reasons.
> +system library paths for security reasons. Also, installation with
> [EMAIL PROTECTED] might not work not OpenBSD, when the
> +package contains shared libraries and libtool versions 1.5.xx are used.
Typo: "
Hello Bruno,
* Bruno Haible wrote on Fri, Mar 02, 2007 at 02:30:07AM CET:
> Ralf Wildenhues wrote:
>
> > > for example, --prefix=/tmp/inst$$.
> >
> > This bit doesn't. Since /tmp is usually world-writable, you've got your
> > attack vector already.
>
> /tmp is world-writable but a directory
* Bruno Haible wrote on Fri, Mar 02, 2007 at 02:48:10AM CET:
> Ralf Wildenhues wrote:
> > I tried some compilers now. All those I tried coped well with multiple
> > source files listed. But just as well, none except GCC are intelligent
> > enough by themselves to not stomp upon each others' objec
22 matches
Mail list logo
