coreutils
[Top][All Lists]
Advanced

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

Re: coreutils-8.12.178-df9cd on AIX


From: Bruno Haible
Subject: Re: coreutils-8.12.178-df9cd on AIX
Date: Fri, 2 Sep 2011 19:58:49 +0200
User-agent: KMail/1.13.6 (Linux/2.6.37.6-0.5-desktop; KDE/4.6.0; x86_64; ; )

Hi Pádraig,

> >   CCLD     split
> > ld: 0711-317 ERROR: Undefined symbol: .pthread_getspecific
> > ld: 0711-317 ERROR: Undefined symbol: .pthread_setspecific
> > ld: 0711-317 ERROR: Undefined symbol: .pthread_key_create
> > ld: 0711-317 ERROR: Undefined symbol: .pthread_once
> > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more 
> > information.
> > make: 1254-004 The error code from the last command is 8.
> > 
> > The reason is that lib/strsignal.o depends on multithreading:
> > 
> > $ nm lib/strsignal.o | grep pthread_once
> > .pthread_once        U           -
> > pthread_once_t:t44=43 -           0
> > 
> > The fix is to add $(LIBTHREAD) to split_LDADD in src/Makefile.am.
> 
> Hmm, that would fix it, but I'm wary of adding the dependency.

Recall that on systems which have weak symbols (glibc systems, Solaris,
and others), $(LIBTHREAD) is empty. Therefore you are adding a dependency
only on less advanced systems.

> Threading is only required to provide a thread safe version of strsignal()
> which will return separate pointers to the strings for each thread.
> I wonder in future could the strsignal replacement only do the threading
> stuff when built with the _REENTRANT define etc.?
> Anyway for the moment we might just remove the use of strsignal()

I wouldn't go this way, because gnulib is going to add more and more
thread-safetiness in the long run. Currently it's only strsignal(); in
the future it may be many more calls.

The basic problem is that coreutils has some programs that use threads,
like 'sort', and some programs which we know are single-threaded. But
code like strsignal.o is only built once and cannot satisfy both at the
same time optimally. Therefore a "perfect" solution would be to split
coreutils into two groups of programs, the multithreaded ones on one
hand and the single-threaded ones on the other hand. If the first group
was built by a configure.ac that enables threading and the second group
was built by a different configure.ac that has threads off by default
(via gl_DISABLE_THREADS), and the two have different config.h files,
then each program can be linked with exactly what it needs. Yes, you
will then have two different strsignal.o files in the build tree, one
that refers to pthread_once and one that doesn't. - How to apply this
separation without making huge changes to the coreutils source tree layout
is an exercise in Autoconfology and Automakology :-)

> > It comes from the fact that 'struct statvfs', defined in <sys/statvfs.h>,
> > has an f_basetype field, but 'struct statfs', which is being used here and
> > which is defined in <sys/statfs.h>, does not have an f_basetype field.
> 
> What fix did you apply here?

I temporarily changed the
  #ifdef STATXFS_FILE_SYSTEM_TYPE_MEMBER_NAME
in src/stat.c:209 to an
  #if 0

> > FAIL: misc/help-version
> 
> env isn't finding [
> Was that built?

$ cd tests
$ cat .built-programs ; echo
[ base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut 
date dd df dir dircolors dirname du echo env expand expr factor false fmt fold 
ginstall groups head hostid id join kill link ln logname ls md5sum mkdir mkfifo 
mknod mktemp mv nice nl nohup nproc od paste pathchk pinky pr printenv printf 
ptx pwd readlink rm rmdir runcon seq sha1sum sha224sum sha256sum sha384sum 
sha512sum shred shuf sleep sort split stat stty sum sync tac tail tee test 
timeout touch tr true truncate tsort tty uname unexpand uniq unlink uptime 
users vdir wc who whoami yes 

But the '[' program was not built:
$ cd src
$ make ; ls -l '['
        make  all-am
Target "all-am" is up to date.
ls: 0653-341 The file [ does not exist.
$ gmake ; ls -l '['
gmake  all-am
gmake[1]: Entering directory 
`/home/haible/multibuild-1209/aix61-cc/coreutils-8.12.178-df9cd/src'
  CC       lbracket.o
  CCLD     [
gmake[1]: Leaving directory 
`/home/haible/multibuild-1209/aix61-cc/coreutils-8.12.178-df9cd/src'
-rwxrwxr-x    1 haible   haible       284215 Sep 02 17:54 [

As you can see, AIX 'make' does not want to build '['.

> > FAIL: split/l-chunk
> 
> This will probably avoid that issue:
> 
> diff --git a/tests/split/l-chunk b/tests/split/l-chunk
> index 7bf6989..e1c9ec7 100755
> --- a/tests/split/l-chunk
> +++ b/tests/split/l-chunk
> @@ -108,7 +108,7 @@ for ELIDE_EMPTY in '' '-e'; do
>          echo "$lines"
>        fi
>      done
> -    test "$ELIDE_EMPTY" && EXP=exp.elide_empty || EXP=exp
> +    test -z "$ELIDE_EMPTY" && EXP=exp || EXP=exp.elide_empty
>      compare out $EXP || fail=1
>    done
>  done

Yes. This simpler change fixes it as well:

--- split/l-chunk.bak   Mon Aug  8 07:42:16 2011
+++ split/l-chunk       Fri Sep  2 17:56:59 2011
@@ -108,7 +108,7 @@
         echo "$lines"
       fi
     done
-    test "$ELIDE_EMPTY" && EXP=exp.elide_empty || EXP=exp
+    test -n "$ELIDE_EMPTY" && EXP=exp.elide_empty || EXP=exp
     compare out $EXP || fail=1
   done
 done


-- 
In memoriam Robert Mensah <http://en.wikipedia.org/wiki/Robert_Mensah>



reply via email to

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