When building on Fedora 23 with a previously working configuration I receive the following error: ls: symbol lookup error: ls: undefined symbol: cap_get_file configure: error: working directory cannot be determined This is caused by the by the following lines in the configure script. 1127 ac_pwd=`pwd` && test -n "$ac_pwd" && 1128 ac_ls_di=`ls -di .` && 1129 ac_pwd_ls_di=`cd "$ac_pwd" && ls -di .` || 1130 as_fn_error $? "working directory cannot be determined" 1131 test "X$ac_ls_di" = "X$ac_pwd_ls_di" || 1132 as_fn_error $? "pwd does not report name of working directory" This line calls /bin/ls as there is no host ls provided by buildroot, but ls uses LD_LIBRARY_PATH as set by buildroot to locate the shared libraries it requires and therefore opens: ${buildpath}/host/usr/lib/libcap.so.2 The same effect can be achieved by typing: LD_LIBRARY_PATH=${buildpath}/host/usr/lib ls -dl . Temperately modifying the configure script to be: 1127 LD_LIBRARY_PATH= ac_pwd=`pwd` && test -n "$ac_pwd" && 1128 ac_ls_di=`ls -di .` && 1129 ac_pwd_ls_di=`cd "$ac_pwd" && ls -di .` || 1130 as_fn_error $? "working directory cannot be determined" 1131 test "X$ac_ls_di" = "X$ac_pwd_ls_di" || 1132 as_fn_error $? "pwd does not report name of working directory" Allows the build to continue. But the same problem is encountered in building other host packages. But it would appear to be a dependency issue. I think the build order should be that host-coreutils and host-libcap needs to be build before any other host packages that use ls (or any other commands used in configure scripts).
Ian, All, Thanks for the report. We've already had this bug reported on the list, and a patch was submitted with the same proposal as yours, i.e. make host-libcap a dpeendency of host-coreutils, itself a dependency of host-pkgconf. However, we believe this is the wrong solution. We are aiming at getting rid of LD_LIBRARY_PATH instead, since we are supposed to have proper RPATH in all our generated host binaries, which should make LD_LIBRARY_PATH unnecessary. Still, there are a few of our host binaries that still do not have a proper RPATH set, and fixing those is not a trivial task. So, the short-term action is to collect all our host binaries that still lack a proper RPATH, see which ones need it: a host binary that only has dependencies on the C library and similar host libraries, like stdc++, does not require RPATH. We need to investgate those, fix them when needed, and finally get rid of LD_LIBRARY_PATH altogether. Any help in this endeavour will be greatly appreciated! ;-) Regards, Yann E. MORIN.
Yes I agree removing LD_LIBRARY_PATH is a much better solution. I had thought of that as a possibility myself, but didn't suggest it because of the amount of work involved. As I need to get my build working again quickly I will probably do the coreutils fix as a stop gap. If I do do this, I will, of course, make a patch available.
Created attachment 6221 [details] Add host coreutils and add some host build dependancies I'm not claiming to have added all of the required dependencies. but A) Buildroot now builds for me on Fedora 23 B) This makes things no worse C) pkgconfig and anything dependent on it now has correct dependencies and uses compatible ls and libcap
(In reply to comment #3) > Created attachment 6221 [details] > Add host coreutils and add some host build dependancies > > I'm not claiming to have added all of the required dependencies. but > > A) Buildroot now builds for me on Fedora 23 > B) This makes things no worse > C) pkgconfig and anything dependent on it now has correct dependencies and uses > compatible ls and libcap As Yann said, we believe this is not the proper direction. Instead, removing LD_LIBRARY_PATH should be done, so that for your system tools, we don't try to use the Buildroot built libraries. Can you test the patch at http://patchwork.ozlabs.org/patch/537657/ instead ? Thanks!
I've build successfully with the patch from http://patchwork.ozlabs.org/patch/537657/
Ian, All, Fixed by this commit: http://git.buildroot.net/buildroot/commit/?id=34d081674ab8f0ffad84e5a18d3c67855826262f Thanks for the report! Regards, Yann E. MORIN.