bug#7142: coreutils on Solaris 10(x86) 09/10

[Eric Blake]

On 10/04/2010 02:45 AM, Clemens Brogi wrote:
> > > I was able to build 8.5 after defining LDFLAGS -lgen
> >
> > Which .o file needed -lgen before compilation worked? We'd like to fix
> > that before coreutils 8.6.
>
> Hi
>
> as far as I can figure it out, the error only occoures if I use suncc as CC
>
> I have attached the the config and make output

Thanks - the culprit is (at least) chroot.c:

>   CCLD     chroot
> Undefiniertes                   erstmals referenziert
>  Symbol                             in Datei
> eaccess                             ../lib/libcoreutils.a(euidaccess.o)
> ld: Schwerer Fehler: Symbolreferenzierungsfehler. Keine Ausgabe in chroot 
> geschrieben

And the fix is probably pretty easy (in our makefile, $(LIB_EACCESS) is 
already -lgen on Solaris):

diff --git i/src/Makefile.am w/src/Makefile.am
index 00c7ff7..aaff18d 100644
--- i/src/Makefile.am
+++ w/src/Makefile.am
@@ -307,8 +307,9 @@ rm_LDADD += $(remove_LDADD)
 # for eaccess, euidaccess
 copy_LDADD += $(LIB_EACCESS)
 remove_LDADD += $(LIB_EACCESS)
 test_LDADD += $(LIB_EACCESS)
+chroot_LDADD += $(LIB_EACCESS)

 # for selinux use
 chcon_LDADD += $(LIB_SELINUX)
 copy_LDADD += $(LIB_SELINUX)


The problem is, I don't know the root cause for why the fix is needed, 
so I'm hesitant to apply the patch without figuring why, so that we can 
document any other function that should be looked for when maintaining 
the list of $(LIB_EACCESS) clients.  That is, what is the actual 
dependency chain of symbols that ultimately ends up dragging in eaccess 
to resolve something present in chroot.o?

'cd gnulib; git grep eaccess lib' shows that findprog.c (irrelevant to 
coreutils) and euidaccess.c are the only clients that need eaccess.  In 
turn, euidaccess is only used by faccessat.c, and I don't see any other 
uses of faccessat() in gnulib or in chroot.c (I do, however, see 
euidaccess used in remove.c, copy.c, and test.c, explaining the existing 
three link setups in the above patch).

Meanwhile, running 'make -k' to see if any other programs are also 
impacted might be a useful test, as would playing with nm to figure out 
the dependency chain that is trying to pull in eaccess to resolve a 
symbol in chroot.o.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org