Simon,
> I looked into that, but it seems to depend on libtool.
Yes, the @NM@ and @GLOBAL_SYMBOL_PIPE@ values are determined by libtool.m4.
> Have you tested this solution on many platforms?
Yes, it has already undergone the testing of two gettext releases.
> I could see if I can make gnulib-t
Simon Josefsson wrote:
> > ... except for gc_hash_hmac_setkey.
>
> Would implementing that function in gc-gnulib.c solve the problem?
Maybe. Maybe the problem was a difference between two different versions
of gnulib; then it will not solve the problem.
> Perhaps there should be some #define's h
> I did not bump the argz.m4 serial again (I'm not sure what the
> rules are: bump on EVERY change
Personally I think it is highly desirable to change serial numbers
any time a new version is committed. One person's minor fix is another
person's critical stopper.
Hi Charles, Bruno,
* Charles Wilson wrote on Thu, Apr 26, 2007 at 07:34:56AM CEST:
>
> Attached. Re-ran *all* of the tests described here:
> http://lists.gnu.org/archive/html/libtool-patches/2007-04/msg00073.html
> with identical results.
Thank you for patching and testing, and thanks to Bruno f
FYI ...
At the initiation of other GNU webmasters, I've installed a change that
makes the gendocs_template file used by gendocs.sh conform to the
current GNU style. (With that lengthy header and navbar ... not really
my favorite, but so it goes.)
At least for the time being, I saved the previous
Charles Wilson wrote:
I'll generate and
test an additional patch addressing Bruno's concerns.
Attached. Re-ran *all* of the tests described here:
http://lists.gnu.org/archive/html/libtool-patches/2007-04/msg00073.html
with identical results.
I did not bump the argz.m4 serial again (I'm not su
On Wed, 25 Apr 2007 23:57:13 +0200, "Bruno Haible" <[EMAIL PROTECTED]>
[Lots of good comments...snipped]
As I was the originator of this change (though not its final form), and
because Ralf has already committed it to libtool cvs, I'll generate and
test an additional patch addressing Bruno's conc
According to Eric Blake on 4/25/2007 7:22 AM:
> Thanks. The next problem is figuring out how to work around the fact that
> on mingw, fflush(stdin) returns 0 and moves the file offset to the end of
> the buffer, rather than failing with EBADF, unlike all the other platforms
> where fflush(stdin) i
According to Eric Blake on 4/25/2007 11:18 AM:
> According to Bruno Haible on 4/13/2007 6:30 PM:
>> I got these working reasonably only on glibc. Portability problems occurred
>> on Solaris, OSF/1, AIX, MacOS X, IRIX, HP-UX. If someone wants to continue,
>> here's the code.
>
> What sort of proble
Eric Blake <[EMAIL PROTECTED]> writes:
> According to Simon Josefsson on 4/3/2007 4:22 AM:
>> "Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
>>
>>> Hi Eric,
>>>
>>> Please either, indent patches so that gpg doesn't escape leading '-'
>>> signs, or use S/MIME for attaching as separate gpg signature
According to Simon Josefsson on 4/3/2007 4:22 AM:
> "Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
>
>> Hi Eric,
>>
>> Please either, indent patches so that gpg doesn't escape leading '-'
>> signs, or use S/MIME for attaching as separate gpg signature.
>
> I think you meant PGP/MIME (RFC3156), S/M
Bruno Haible <[EMAIL PROTECTED]> writes:
> Yes. Ralf was the first one to realize the need for such a renaming. It can
> be done in a Makefile.am rule without special help from gnulib-tool. See
> gettext/gettext-tools/libgettextpo/Makefile.am.
I looked into that, but it seems to depend on libtool
* Simon Josefsson wrote on Thu, Apr 26, 2007 at 01:30:02PM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> >
> > It's roughly like this: the linker goes through the archive. For each
> > object file, it decides whether it needs symbols from it. If yes, that
> > object is added to the output
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
Or is there some libtool/ld/etc setting that gnulib or my
projects should use, to avoid causing this situation?
>>>
>>> Such errors when linking statically typically occur when you have object
>>> files defining more than one symbol. The rest o
* Simon Josefsson wrote on Thu, Apr 26, 2007 at 10:44:41AM CEST:
> On 26 apr 2007, at 01.04, Bruno Haible wrote:
>> Simon Josefsson wrote:
>
> But yes, gc-libgcrypt and gc-gnulib are intended to be two mutually
> exclusive modules, since they provide the same symbols, but I wouldn't have
> though
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> But yes, gc-libgcrypt and gc-gnulib are intended to be two mutually
>> exclusive modules, since they provide the same symbols
>
> ... except for gc_hash_hmac_setkey.
Would implementing that function in gc-gnulib.c solve the pr
Simon Josefsson wrote:
> But yes, gc-libgcrypt and gc-gnulib are intended to be two mutually
> exclusive modules, since they provide the same symbols
... except for gc_hash_hmac_setkey.
> I had no idea that defining multiple symbols in a single object
> file could lead to trouble. Sigh.
Tha
Eric Blake wrote:
> > Btw, what is AC_FUNC_FSEEKO good for?
>
> AC_FUNC_FSEEKO turns on large file support, if necessary.
Actually, it doesn't. Paul explained it: AC_FUNC_FSEEKO makes the fseeko()
and ftello() declarations visible (and all the *64 struct and function
declarations) but does *not*
Paul Eggert wrote:
> > Btw, what is AC_FUNC_FSEEKO good for?
>
> It checks for systems like glibc 2.2 where you also have to define
> _LARGEFILE_SOURCE to make fseeko visible. I don't see where the
> gnulib fseeko module does that; if it doesn't, shouldn't it?
Indeed. Also with glibc 2.3.6 and "
Eric Blake wrote:
> Meanwhile, I'm checking in this.
>
> 2007-04-25 Eric Blake <[EMAIL PROTECTED]>
>
> * lib/fpurge.c (includes): Use stdlib.h for free.
> * tests/test-fflush.c (main): Also test fflush-fseeko.
Thanks. Addendum:
2007-04-26 Bruno Haible <[EMAIL PROTECTED]>
On 26 apr 2007, at 01.04, Bruno Haible wrote:
Simon Josefsson wrote:
It seems clear that the problem is that both libgnutls and libgsasl
contains the same gnulib symbols.
Uh, you are jumping to the conclusion rather quickly.
Oops. I don't understand the error, so jumping to conclusion isn'
21 matches
Mail list logo
