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
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
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
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
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
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
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
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
> 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
* 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
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
---
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
---
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
* 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
19 matches
Mail list logo
