Hi,
With the latest gnulib-tool update, any invocation of gnulib-tool will
result in symlinked sources files. The patch also fix a --macro-prefix
typo in the 'Reproduce by' summary.
Regards,
--
Yoann Vandoorselaere | Responsable R&D / CTO | PreludeIDS Technologies
Tel: +33 (0)8 70 70 21 58
And now, for the regex patch that I wanted to install originally!
Most of the other regex patches were in preparation for this one.
This patch duplicates some of the ideas from the xmalloc module,
but I judged that better than trying to get the glibc folks to
adopt xmalloc.
The regex code currentl
On Thu, 2005-09-01 at 12:28 +0200, Yoann Vandoorselaere wrote:
> Hi,
>
> An OpenBSD Prelude user reported that GnuLib will fail to compile on
> OpenBSD 3.7 due to the new dependencies of modules like strcase on
> wctype.h and wchar.h headers.
>
> These headers are apparently not available on Ope
Bruno Haible <[EMAIL PROTECTED]> writes:
> You're right, and the patch looks good. OK to commit, Paul?
Yes, and thanks for checking it. I committed it.
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Martin Lambers <[EMAIL PROTECTED]> writes:
> The patch is mostly a recombination of code written by Jim Meyering and
> Bruno Haible, so there should by no copyright problem when including
> this into gnulib.
Hmm, I suspect that it's enough extra work that we'll need papers from
you. Would you be
On Fri, 02. Sep 2005, 12:11:37 -0700, Paul Eggert wrote:
> Hmm, I suspect that it's enough extra work that we'll need papers from
> you. Would you be willing to assign the copyright to the Free Software
> Foundation, so that we could install it in gnulib?
Yes.
> You don't need to check whether
Simon Josefsson <[EMAIL PROTECTED]> writes:
> But I have never understood why one has to sign per-projects form for
> the FSF anyway...
It's a legal thing. When you assign your copyright, you have to
specify what it is you're signing over. Otherwise there could be
abuses of the legal system (yo
On Fri, Sep 02, 2005 at 04:00:10PM +0200, Oskar Liljeblad wrote:
> Hmm, another problem. I've signed a copyright assignment for Gnulib,
> but not for GNU libc. I guess that needs to be signed as well first?
If your assignment was assign.future, the FSF now owns the code and
can do what they like
Simon Josefsson wrote:
> >> It should default to 'libgnu'
> >
> > Yes. Fixed now as well.
>
> It doesn't seem to work:
>
> [EMAIL PROTECTED]:~/src/gnutls$ gnulib-tool --import --source-base=gl
> --m4-base=gl/m4 --lgpl getline error memmem getpass minmax snprintf memmove
> readline gnulib-tool: ***
Simon Josefsson wrote:
> Running "gnulib-tool --import" has become slow:
>
> [EMAIL PROTECTED]:~/src/gnutls$ time gnulib-tool --import
> ...
> real0m47.043s
> user0m19.559s
> sys 0m10.299s
> [EMAIL PROTECTED]:~/src/gnutls$
>
> This is on GnuTLS, which uses:
>
> gl_MODULES([error getline
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> "Oskar Liljeblad" <[EMAIL PROTECTED]> writes:
>>
>>>On Friday, September 02, 2005 at 15:17, Simon Josefsson wrote:
>>>
>It seems iconvme.[ch] was updated in gnulib a few days ago; it used to
>be synced from libc. A
Simon Josefsson wrote:
"Oskar Liljeblad" <[EMAIL PROTECTED]> writes:
On Friday, September 02, 2005 at 15:17, Simon Josefsson wrote:
It seems iconvme.[ch] was updated in gnulib a few days ago; it used to
be synced from libc. Are there libc bug reports or anything to
associate with this, or a
Jim Meyering wrote:
Bruno Haible <[EMAIL PROTECTED]> wrote:
The problem you describe was more of an automake limitation, and
it has been resolved by automake's addition of AC_CONFIG_LIBOBJ_DIR.
Interesting. But AC_CONFIG_LIBOBJ_DIR is documented just between
AC_CONFIG_AUX_DIR and AC_CONFIG_HE
Albert Chin <[EMAIL PROTECTED]> writes:
>> This is what M4 macros in gnulib generally use, is it ok?
>>
>> dnl Copyright (C) 2005 Free Software Foundation, Inc.
>> dnl This file is free software; the Free Software Foundation
>> dnl gives unlimited permission to copy and/or distribute it,
>> dnl w
Running "gnulib-tool --import" has become slow:
[EMAIL PROTECTED]:~/src/gnutls$ time gnulib-tool --import
...
real0m47.043s
user0m19.559s
sys 0m10.299s
[EMAIL PROTECTED]:~/src/gnutls$
This is on GnuTLS, which uses:
gl_MODULES([error getline getpass memmem memmove minmax readline snpr
On Fri, Sep 02, 2005 at 09:26:16AM +0200, Simon Josefsson wrote:
> Albert Chin <[EMAIL PROTECTED]> writes:
>
> > On Thu, Sep 01, 2005 at 01:28:39PM +0200, Simon Josefsson wrote:
> >> Albert Chin <[EMAIL PROTECTED]> writes:
> >>
> >> > We created the following macro for curl. It's been tested on t
Hi Jim,
> The problem you describe was more of an automake limitation, and
> it has been resolved by automake's addition of AC_CONFIG_LIBOBJ_DIR.
Interesting. But AC_CONFIG_LIBOBJ_DIR is documented just between
AC_CONFIG_AUX_DIR and AC_CONFIG_HEADERS, which makes me believe that
only a single cal
"Oskar Liljeblad" <[EMAIL PROTECTED]> writes:
> On Friday, September 02, 2005 at 15:17, Simon Josefsson wrote:
>>
>> > It seems iconvme.[ch] was updated in gnulib a few days ago; it used to
>> > be synced from libc. Are there libc bug reports or anything to
>> > associate with this, or are we ju
Bruno Haible <[EMAIL PROTECTED]> writes:
>> [EMAIL PROTECTED]:~/src/gnutls$ gnulib-tool --import --macro-prefix=lgl
>> --source-base=lgl --m4-base=lgl/m4 memmem gnulib-tool: *** missing --lib
>> option
>> gnulib-tool: *** Stop.
>> [EMAIL PROTECTED]:~/src/gnutls$
>>
>> It should default to 'libgnu'
Simon Josefsson wrote:
> Btw, can't we make a module for this? readline need the macro, and
> was only including m4/lib-link.m4, not lib-prefix.m4, and maintaining
> which m4 macros depend on each other manually for every module seems
> like work. Better to make a "lib-link" module, and make read
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> Btw, can't we make a module for this? readline need the macro, and
>> was only including m4/lib-link.m4, not lib-prefix.m4, and maintaining
>> which m4 macros depend on each other manually for every module seems
>> like work. B
Bruno Haible <[EMAIL PROTECTED]> wrote:
>> The problem you describe was more of an automake limitation, and
>> it has been resolved by automake's addition of AC_CONFIG_LIBOBJ_DIR.
>
> Interesting. But AC_CONFIG_LIBOBJ_DIR is documented just between
> AC_CONFIG_AUX_DIR and AC_CONFIG_HEADERS, which m
On Friday, September 02, 2005 at 15:17, Simon Josefsson wrote:
>
> > It seems iconvme.[ch] was updated in gnulib a few days ago; it used to
> > be synced from libc. Are there libc bug reports or anything to
> > associate with this, or are we just forked?
>
> Oops, I had forgot we were synced. O
[EMAIL PROTECTED] (Karl Berry) writes:
> It seems iconvme.[ch] was updated in gnulib a few days ago; it used to
> be synced from libc. Are there libc bug reports or anything to
> associate with this, or are we just forked?
Oops, I had forgot we were synced. Oskar, do you want to file a glibc
bu
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> Further, does this macro handle 64-bit libraries in $prefix/lib64?
>
> I have committed this untested patch. Do you have time to try it on a mixed
> 32/64-bit system?
I'm installing it in GnuTLS/GSASL and will report if it break
It seems iconvme.[ch] was updated in gnulib a few days ago; it used to
be synced from libc. Are there libc bug reports or anything to
associate with this, or are we just forked?
Thanks,
k
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Paul, Jim, Alexandre,
>
> gnulib-tool now supports multiple gnulib directories with a single
> configure.ac. Simon needs this in GnuTLS. I need this in libglocale.
> But half of gnulib doesn't work with gnulib-tool.
>
> Due to AC_LIBSOURCES.
Hi Bruno,
Hi Paul, Jim, Alexandre,
gnulib-tool now supports multiple gnulib directories with a single
configure.ac. Simon needs this in GnuTLS. I need this in libglocale.
But half of gnulib doesn't work with gnulib-tool.
Due to AC_LIBSOURCES.
Paul and Jim, you pushed towards using AC_LIBSOURCES. Could you
Simon Josefsson wrote:
> Further, does this macro handle 64-bit libraries in $prefix/lib64?
I have committed this untested patch. Do you have time to try it on a mixed
32/64-bit system?
Bruno
2005-08-27 Bruno Haible <[EMAIL PROTECTED]>
Support for lib vs. lib64 distinction on biarch
On Fri, 02. Sep 2005, 08:31:26 +0200, Martin Lambers wrote:
> The second patch makes the gettime module use gettimeofday
> unconditionally. It depended on the gettimeofday module before, and
> this small change
> - simplifies the code
> - improves gettime time resolution from seconds to microsecond
Albert Chin <[EMAIL PROTECTED]> writes:
> On Thu, Sep 01, 2005 at 01:28:39PM +0200, Simon Josefsson wrote:
>> Albert Chin <[EMAIL PROTECTED]> writes:
>>
>> > We created the following macro for curl. It's been tested on the
>> > following systems:
>>
>> Has the copyright been assigned to the FSF?
Albert Chin wrote:
On Thu, Sep 01, 2005 at 01:28:39PM +0200, Simon Josefsson wrote:
Albert Chin <[EMAIL PROTECTED]> writes:
We created the following macro for curl. It's been tested on the
following systems:
Has the copyright been assigned to the FSF?
No. I'd like to see a liberal licen
On Thu, 25. Aug 2005, 19:36:23 +0200, Jim Meyering wrote:
> Paul Eggert <[EMAIL PROTECTED]> wrote:
> > I suspect that he'll say it's OK with him as long as it's no real work
> > for him.
>
> That's accurate :)
Then I'd like to propose the following two patches for inclusion.
The first is a revis
33 matches
Mail list logo
