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.
First of all, can the reporter reproduce the problem also when building
without the -ffunction-sections option?
Hi Ralf,
A bit of gnitpicking:
Ralf Wildenhues wrote:
> Here's what the gnulib patch looks like.
> + set x `uname -r | $SED -e 's/^\([[0-9\.]]*\).*/\1/'`
$SED is usually not defined in the context of autoconf macros that are
part of gnulib. (I.e. it expands to empty.) Just use 'sed' in
I've received a report where building GNU SASL, linked to GnuTLS,
fails because both projects use gnulib. Errors look like:
/bin/bash ../libtool --tag=CC --mode=link gcc -Os -ffunction-
sections -fdata-sections -s -Wl,--gc-sections -static -o gsasl
gsasl.o gsasl_cmd.o imap.o smtp.o call
[ http://thread.gmane.org/gmane.comp.gnu.libtool.patches/7314/focus=7498 ]
Thanks Charles for all your work on this. I installed this path into
Libtool HEAD, and pulled the changes over to gnulib. Here's what the
gnulib patch looks like.
Cheers,
Ralf
2007-04-25 Charles Wilson <[EMAIL PROTECT
Bruno Haible <[EMAIL PROTECTED]> writes:
> 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?
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 problems? I got it the tests to work on both cygwin and
mingw
From: Sven Verdoolaege <[EMAIL PROTECTED]>
---
lib/argp-help.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/argp-help.c b/lib/argp-help.c
index 7321480..627bf9e 100644
--- a/lib/argp-help.c
+++ b/lib/argp-help.c
@@ -674,9 +674,9 @@ hol_cluster_cmp (const struct
According to Bruno Haible on 4/25/2007 1:56 AM:
> Eric Blake wrote on 2007-04-17:
>> we also need a module for
>> ftell/ftello (until that is written, fflush fails to compile on mingw).
>
> With this, fflush at least compiles on mingw:
Thanks. The next problem is figuring out how to work around
According to Bruno Haible on 4/25/2007 1:39 AM:
>
> Btw, what is AC_FUNC_FSEEKO good for?
AC_FUNC_FSEEKO turns on large file support, if necessary.
> 2007-04-25 Bruno Haible <[EMAIL PROTECTED]>
>
> * modules/fseeko: New file.
...
> + #if @GNULIB_FSEEKO@
> + # if [EMAIL PROTECTED]@
> + /
On 2007-04-13, I wrote:
> 2) fseek() is heavily optimized: fseeko (fp, pos, SEEK_SET) will position
>the file descriptor to pos & ~fp->_blksize and then read one buffer,
>[or if pos is inside the current buffer, optimize even more: just
>change some pointers and counters, without
Eric Blake wrote on 2007-04-17:
> we also need a module for
> ftell/ftello (until that is written, fflush fails to compile on mingw).
With this, fflush at least compiles on mingw:
2007-04-25 Bruno Haible <[EMAIL PROTECTED]>
* modules/fflush (Depends-on): Add ftello.
*** modules/fflush
Eric Blake wrote on 2007-04-17:
> I discovered that mingw lacks ftello, so we also need a module for
> ftell/ftello
2007-04-25 Bruno Haible <[EMAIL PROTECTED]>
* modules/ftello: New file.
* m4/ftello.m4: New file.
* m4/stdio_h.m4 (gl_STDIO_H_DEFAULTS): Set also GNULIB_FT
Eric Blake wrote on 2007-04-17:
> A module for fseek/fseeko still needs to be written. And in the process,
> I discovered that mingw lacks ftello, so we also need a module for
> ftell/ftello (until that is written, fflush fails to compile on mingw).
> Unfortunately, on mingw, Microsoft has chosen
For the later support of "gnulib-tool --posixcheck" (or similar), I'm
applying this:
2007-04-25 Bruno Haible <[EMAIL PROTECTED]>
* lib/stdio_.h (fflush): Add support for GNULIB_POSIXCHECK.
*** lib/stdio_.h10 Apr 2007 03:09:07 - 1.16
--- lib/stdio_.h25 Apr 2007
14 matches
Mail list logo
