| Summary: | Bootstrapping coreutils fails on Gentoo FreeBSD 9 (amd64-fbsd) | ||
|---|---|---|---|
| Product: | Gentoo/Alt | Reporter: | Richard Yao (RETIRED) <ryao> |
| Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | cnyegle |
| Priority: | Normal | Keywords: | Bug, REGRESSION |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | FreeBSD | ||
| Whiteboard: | Verify fix is in >=coreutils-8.18 | ||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Log of bootstrap failure
Patch from sys-apps/coreutils-8.17 patchset 1.1 |
||
The FreeBSD bootstrap procedure still says to use coreutils8, but that was removed from bootstrap-prefix.sh. Reintroducing it will workaround this issue. Is the solution REALLY to use a back-level version of coreutils or can something be fixed upstream? I have a hard time believing that coreutils stopped supporting freebsd or such. checking for pthread.h... (cached) yes checking for pthread_kill in -lpthread... yes feels more like they forgot PTHREAD_LIBS or whatever (In reply to comment #3) > checking for pthread.h... (cached) yes > checking for pthread_kill in -lpthread... yes > > feels more like they forgot PTHREAD_LIBS or whatever Currently autotools sets LIB_PTHREAD=-lpthread iff pthread_join() is in libc. This causes a failure on FreeBSD where pthread_join() is in libc and pthread_create() is in libpthread.so. Switching the pthread_join check to a pthread_create check would be the simplest way of addressing this on FreeBSD, but the big question is whether or not that will cause a similar regression on another platform, which would require that a more elaborate check be done. (In reply to comment #2) > Is the solution REALLY to use a back-level version of coreutils or can > something be fixed upstream? I have a hard time believing that coreutils > stopped supporting freebsd or such. Which version of coreutils should be patched? bootstrap-prefix.sh currently installs 8.16, but 8.17 is out. It might be better to patch the new version. sed -i -e s/LIB_PTHREAD/LIBMULTITHREAD/ src/Makefile.{am,in}
(In reply to comment #5) > sed -i -e s/LIB_PTHREAD/LIBMULTITHREAD/ src/Makefile.{am,in} Is that appropriate to send upstream? Does it work in the first place? (In reply to comment #7) > Does it work in the first place? I tried editing the bootstrap script to do this. It does not appear to work. My change was to add this to bootstrap_gnu below the existing coreutils check: [[ ${A%-*} == "coreutils" ]] && \ sed -i -e s/LIB_PTHREAD/LIBMULTITHREAD/ "${S}/src/Makefile".{am,in} I would give --disable-threads a try first I cannot try this, because I'm still on 8.2 where this seems to work fine (In reply to comment #10) > I cannot try this, because I'm still on 8.2 where this seems to work fine I had some things come up yesterday, which prevented me from testing this. Anyway. --disable-threads does not have any effect. The sortlines function in ./src/sort.c does have any preprocessor directives to permit --disable-threads to disable its dependency on pthreads. *** Bug 412485 has been marked as a duplicate of this bug. *** Running `cd ${EPREFIX}/tmp/var/tmp/coreutils-8.16/coreutils-8.16 && sed -i -e 's/LIB_PTHREAD =/& -lpthread/' ./src/Makefile && make && make install` will workaround this problem.
Fixing it will require modifying ./m4/pthread.m4 and rebuilding the ./configure script.
./m4/pthread.m4 does not exist in the coreutils repository. Where does this file originate? I have the answer to my own question. Someone put it in the tarball that is on the FSF's FTP server. This is not under version control. I am going to contact the upstream maintainers. It seems that ./m4/pthread.m4 is from gnulib, which coreutils uses. This regression was caused by commit a6322904ea944ba119aaa62c0c3ee7cfade8b59c: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blobdiff;f=m4/pthread.m4;h=1ac8027dda9ee18ae38895295f2b18dc65ad9595;hp=b60dbc850633fecbffbf4d9c4d6a923316f413b7;hb=a6322904ea944ba119aaa62c0c3ee7cfade8b59c;hpb=6563cd7648f78ce137eb66d4a9a77f9f1666d17f Coreutils 8.12 is the last version that predates that commit. I have sent the gnulib developers an email describing the problem. Hopefully, they will produce a proper fix. Upstream has written a patch: http://lists.gnu.org/archive/html/bug-gnulib/2012-07/msg00043.html I have verified that it works. (In reply to comment #18) > Upstream has written a patch: > > http://lists.gnu.org/archive/html/bug-gnulib/2012-07/msg00043.html > > I have verified that it works. The patch has been committed: http://lists.gnu.org/archive/html/bug-gnulib/2012-07/msg00045.html so, you need 8.12 until a coreutils gets released with the pushed fix to gnulib? Guess I/we can live with 8.12... (In reply to comment #20) > so, you need 8.12 until a coreutils gets released with the pushed fix to > gnulib? There is the option of adopting a patched coreutils tarball like the python tarball. Otherwise, this is correct. > Guess I/we can live with 8.12... This is the easiest thing to do. Created attachment 317928 [details, diff]
Patch from sys-apps/coreutils-8.17 patchset 1.1
We could modify bootstrap prefix to fetch and apply a patch to workaround this. I have attached the patch that went into the coreutils patchset to resolve this.
(In reply to comment #22) > Created attachment 317928 [details, diff] [details, diff] > Patch from sys-apps/coreutils-8.17 patchset 1.1 > > We could modify bootstrap prefix to fetch and apply a patch to workaround > this. I have attached the patch that went into the coreutils patchset to > resolve this. The prefix-overlay coreutils ebuild is unaffected by this issue because of these lines: # m4/pthread.m4 on FreeBSD thinks pthread_join doesn't need any libaries # sort.c:(.text+0x4f25): undefined reference to `pthread_create' [[ ${CHOST} == *-freebsd* ]] && export gl_cv_search_pthread_join=-pthread Those lines could be deleted if patchset 1.1 is imported from the main tree. With that said, we could modify bootstrap-prefix.sh to do this, which would close this bug. (In reply to comment #22) > Created attachment 317928 [details, diff] [details, diff] > Patch from sys-apps/coreutils-8.17 patchset 1.1 > > We could modify bootstrap prefix to fetch and apply a patch to workaround > this. I have attached the patch that went into the coreutils patchset to > resolve this. That isn't advisable. The priority here is low so we can leave the bug open and wait for two things 1) a new release that has the fix, 2) other users to complain and thus the priority increases. For now, I've just added back 8.12 to bootstrap-prefix.sh. Feel free to fix the documentation, please. % svn di Index: bootstrap-prefix.sh =================================================================== --- bootstrap-prefix.sh (revision 61051) +++ bootstrap-prefix.sh (working copy) @@ -819,6 +819,11 @@ bootstrap_gnu coreutils 8.16 } +# bug 415439 +bootstrap_coreutils812() { + bootstrap_gnu coreutils 8.12 +} + bootstrap_tar() { bootstrap_gnu tar 1.26 } (In reply to comment #24) > (In reply to comment #22) > > Created attachment 317928 [details, diff] [details, diff] [details, diff] > > Patch from sys-apps/coreutils-8.17 patchset 1.1 > > > > We could modify bootstrap prefix to fetch and apply a patch to workaround > > this. I have attached the patch that went into the coreutils patchset to > > resolve this. > > That isn't advisable. The priority here is low so we can leave the bug open > and wait for two things 1) a new release that has the fix, 2) other users to > complain and thus the priority increases. I agree. A simpler option would be to modify bootstrap-prefix.sh to do `[[ ${CHOST} == *-freebsd* ]] && export gl_cv_search_pthread_join=-pthread` when bootstrapping coreutils. I spotted that in the prefix overlay's coreutils ebuild when trying to understand why it did not need my patch. bootstrap-prefix.sh now does a iterative loop over versions until one succeeds |
Created attachment 311393 [details] Log of bootstrap failure I tried installing Gentoo Prefix on a virtual machine running Gentoo FreeBSD 9 (amd64-fbsd). Unfortunatley, that fails with the following: sort.o: In function `sortlines': /home/richard/gentoo/tmp/var/tmp/coreutils-8.16/coreutils-8.16/src/sort.c:3572: undefined reference to `pthread_create' Autotools assumes that the presence of pthread_join() in the system library implies the presence of pthread_create(), so the ./configure script will check for pthread_join() in libc and assume that pthread_create() is also in libc. This is not the case in FreeBSD 9's libc, which results in a Makefile that does not pass -lpthread to the linker. This causes a linker failure in sortlines.