When building a testdir with --enable-threads=pth --with-libpth-prefix=...
I see link errors:
gcc -g -O2 -o test-fstrcmp test-fstrcmp.o libtests.a ../gllib/libgnu.a
libtests.a-lm -lm -lm -lm -lm -lm -lm -lm -lm -lm -lm
../gllib/libgnu.a(lock.o): In function `glthread_rwlock_init_multithrea
Hi,
Tom G. Christensen wrote:
> A number of test cases currently fail to build on platforms that depend
> on libintl for gettext functions.
>
> From Solaris 9/x86:
>
> gcc -std=gnu11 -g -O2 -L/usr/tgcware/lib -R/usr/tgcware/lib -o
> test-array_map test-array_map.o ../gllib/libgnu.a -lm -l
Another incorrect 'Link' section is the one in the 'regex' module:
- It needs to inherit the link directive from the 'lock' module.
This is needed on AIX 7 (and probably on HP-UX 11.11, see the
earlier report [1][2]).
- It also needs a reference to libintl. (Reported in [3].)
Paul's patch in r
A few modules compute the link dependencies through an Autoconf macro,
but need also to consider other dependencies. This patch fixes them.
2019-01-04 Bruno Haible
Fix some 'Link' sections.
* modules/c-stack (Link): Add link directive from the 'gettext-h'
dependency.
Some 'Link' sections are not wrong; they are just redundant.
2019-01-04 Bruno Haible
Remove redundant 'Link' sections.
* modules/canon-host (Link): Remove section.
* modules/timevar (Link): Likewise.
diff --git a/modules/canon-host b/modules/canon-host
index c9628da..
Now that we have the right tool for determining the recursive link dependencies
of modules, it becomes apparent that some of the 'Link' fields are incorrect:
- acl, faccessat, fdutimensat, propername, unicodeio, utimecmp, utimensat,
xstriconv, xstriconveh lack
'$(LTLIBINTL) when linking with l
With the clarified meaning of the 'Link' filed in the module description,
it is now clear that the user of a module should generally *not* look
at the 'Link' field in this module description, because in 90% of the
cases this field is missing although the module has link dependencies.
So, we need a
Currently, the meaning of the 'Link' section in the module description
is not clear: If absent, does it mean that the user of the module needs
no libraries on the link command line? Or does it mean that the user
needs to collect the 'Link' section of all dependencies?
We need to consider two kinds
The gnulib documentation says about the 'Link' field:
"Please write them one per line, so that gnulib-tool can remove
duplicates when presenting a summary to the user."
Let's do that, really.
2019-01-04 Bruno Haible
pselect: Fix module description.
* modules/pselect (Link):
m4/cosl.m4 determines the variable COSL_LIBM. That's the variable
needed by the 'cosl' module.
2019-01-04 Bruno Haible
cosl: Fix module description.
* modules/cosl (Link): Fix typo.
* modules/mathl (configure.ac): Likewise.
diff --git a/modules/cosl b/modules/cosl
ind
lib/c-xvasprintf includes xalloc.h and invokes xalloc_die().
The module therefore needs to depend on either 'xalloc' or 'xalloc-die'.
2019-01-04 Bruno Haible
c-xvasprintf: Fix module dependencies.
* modules/c-xvasprintf (Depends-on): Add 'xalloc-die'.
diff --git a/modules/c-x
> Le 4 janv. 2019 à 16:56, Jim Meyering a écrit :
>
> Looks fine to me.
> comment nit: s/non-initialized/uninitialized/
Fixed and pushed, thanks!
On Fri, Jan 4, 2019 at 7:42 AM Akim Demaille wrote:
...
> > Le 2 janv. 2019 à 06:27, Jim Meyering a écrit :
> >
> > Hi Akim,
> >
> > My only concern is that `pwd` may sometimes fail to match the link
> > name when it should. E.g., when mount points or directory symlinks are
> > involved.
> >
> >
Hi Jim!
> Le 2 janv. 2019 à 06:27, Jim Meyering a écrit :
>
> Hi Akim,
>
> My only concern is that `pwd` may sometimes fail to match the link
> name when it should. E.g., when mount points or directory symlinks are
> involved.
>
> Instead, can you simply make the bootstrap script fail when the
* Tim Rühsen:
> But I still wonder why
>
> - nested functions need an executable stack (why does the code have to
> be run on the stack ?)
The static chain pointer needs to be passed to the nest function, but
most ABIs only have a code pointer. So a trampoline is written to the
stack which sets
A module shouldn't rely on internals of another module.
bitsetv.c invokes xalloc_die(), therefore it should #include "xalloc.h",
regardless whether bitset.h already - indirectly through bitset/base.h -
includes xalloc.h.
2019-01-04 Bruno Haible
bitsetv: Fix module dependencies.
xalloc_die() is declared in xalloc.h. No need to declare it also in xmemdup0.h.
2019-01-04 Bruno Haible
xmemdup0: Remove redundant code.
* lib/xmemdup0.h (xalloc_die): Remove declaration.
diff --git a/lib/xmemdup0.h b/lib/xmemdup0.h
index 5ef4995..768f0b2 100644
--- a/lib/xme
lib/backup-find.c include xalloc.h and invokes xalloc_die(). Therefore:
2019-01-04 Bruno Haible
backupfile: Fix module dependencies.
* modules/backupfile (Depends-on): Add 'xalloc'.
diff --git a/modules/backupfile b/modules/backupfile
index 4ada3f5..5dcf6c7 100644
--- a/modul
Florian Weimer wrote:
> > Oh well. Then it's even POSIX compliant. But HP-UX (and possibly
> > Windows) is the only platform where things are really like this -
> > otherwise we would have seen more platforms where the diffutils
> > 'new-file' test fails.
>
> glibc does this as well if the process
* Bruno Haible:
> Oh well. Then it's even POSIX compliant. But HP-UX (and possibly
> Windows) is the only platform where things are really like this -
> otherwise we would have seen more platforms where the diffutils
> 'new-file' test fails.
glibc does this as well if the process underwent an AT_
20 matches
Mail list logo
