[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: bug#7142: coreutils on Solaris 10(x86) 09/10
Date: Mon, 04 Oct 2010 11:48:33 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100921 Fedora/3.1.4-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.4

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.


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 

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
 remove_LDADD += $(LIB_EACCESS)
+chroot_LDADD += $(LIB_EACCESS)

 # for selinux use
 chcon_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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]