Experimental Physics and Industrial Control System
|
Hi Pierrick,
Sorry for the delay...
On 7/2/19 1:56 PM, Pierrick M Hanlet via Tech-talk wrote:
I'm attempting to build EPICS base for a VMIVME7805 intel based VME card. The kernel I
have is 3.16.7. We are using Buildroot on an SL7.5 host machine. I'm attempting to build
3.14.12.8.
I had found Bruno Martins' wiki page:
https://wiki-ext.aps.anl.gov/epics/index.php/How_To_cross_compile_EPICS_and_a_IOC_to_an_old_x86_Linux_system
which is very helpful. However, Buildroot segregates the build tools from the lib & bin & include
files.
From Buildroot, my build tools are in:
.../host/usr/bin/i686-buildroot-linux-uclibc/
And, my staged lib & include & bin files are in:
.../host/staging/.
So, here's what I have in ./base/configure/os/CONFIG_SITE.Common.linux-686:
# Location of the cross-compile toolchain
VMIVME=/usr/local/products/elsd/vmivme7805/linux-3.16.7_generic/output
GNU_DIR=$(VMIVME)/host/usr
GNU_TARGET=i686-buildroot-linux-uclibc
SHRLIB_DEPLIB_DIRS += $(VMIVME)/staging/usr/lib
PROD_DEPLIB_DIRS += $(VMIVME)/staging/usr/lib
In order to get the headers correct, I also modified ./base/configure/CONFIG.CrossCommon:
#GNU_TARGET_INCLUDE_DIR = $(wildcard $(GNU_TARGET:%=$(GNU_DIR)/%/include))
#GNU_TARGET_LIB_DIR = $(wildcard $(GNU_TARGET:%=$(GNU_DIR)/%/lib))
GNU_TARGET_INCLUDE_DIR = $(VMIVME)/staging/usr/include
GNU_TARGET_LIB_DIR = $(VMIVME)/staging/usr/lib
In many cases instead of modifying a core build file (which in this case will also affect any other cross-build targets) you should be able to override build variable values in your configure/os/CONFIG_SITE.Common.linux-686 file. The CROSS_INCLUDES and CROSS_LDFLAGS
macro assignments that use those values don't actually get expanded until they are used to generate a compiler or link line. However this won't affect this issue.
It appears that I can compile everything; for example (the last compile command):
/usr/local/products/elsd/vmivme7805/linux-3.16.7_generic/output/host/usr/bin/i686-buildroot-linux-uclibc-g++ -o libCom.so.3.14 -shared -fPIC -L/usr/local/products/elsd/vmivme7805/linux-3.16.7_generic/output/staging/usr/lib -Wl,-rpath,/usr/local/products/elsd/vmivme7805/linux-3.16.7_generic/output/staging/usr/lib
-m32 -L/usr/local/products/elsd/vmivme7805/linux-3.16.7_generic/output/host/usr/../../staging/usr/lib bucketLib.o epicsRingPointer.o epicsRingBytes.o postfix.o calcPerform.o cvtFast.o resourceLib.o epicsOnce.o epicsSingletonMutex.o dbmf.o ellLib.o
envSubr.o envData.o errlog.o errSymLib.o errSymTbl.o fdmgr.o fdManager.o freeListLib.o gpHashLib.o iocsh.o registry.o libComRegister.o iocLog.o logClient.o macCore.o macEnv.o macUtil.o aToIPAddr.o adjustment.o cantProceed.o epicsConvert.o epicsExit.o epicsStdlib.o
epicsString.o truncateFile.o ipAddrToAsciiAsynchronous.o epicsUnitTest.o epicsThread.o epicsMutex.o epicsEvent.o epicsTime.o epicsMessageQueue.o epicsMath.o epicsGeneralTime.o osiClockTime.o osdSock.o osdSockAddrReuse.o osiSock.o systemCallIntMech.o epicsSocketConvertErrnoToString.o
osdAssert.o osdFindSymbol.o osdInterrupt.o osdPoolStatus.o osdSignal.o osdEnv.o epicsReadline.o epicsTempFile.o epicsStdio.o osdStdio.o osdThread.o osdMutex.o osdEvent.o osdTime.o osdProcess.o osdNetIntf.o osdMessageQueue.o devLibVME.o devLibVMEOSD.o taskwd.o
epicsTimer.o timer.o timerQueue.o timerQueueActive.o timerQueueActiveMgr.o timerQueuePassive.o tsDefs.o -lpthread -lreadline -lncurses -lm -lrt -ldl -lgcc
Actually that's a link command, EPICS uses g++ to link programs rather than ld because we have lots go C++ code, and the linking process may require instantiating C++ templates which ld can't do (or it didn't used to be able to). Is the following quote the
next line of output (which would be an error from the above g++ command), or the output from a command which you elided?
But when it comes to loading shared libraries, it fails (next command in make):
/scratch/products/elsd/vmivme7805/linux-3.16.7_generic/output/host/usr/bin/../lib/gcc/i686-buildroot-linux-uclibc/4.8.3/../../../../i686-buildroot-linux-uclibc/bin/ld: cannot find /lib/libubacktrace.so.0
collect2: error: ld returned 1 exit status
make[3]: *** [libCom.so.3.14] Error 1
Firstly, I didn't understand why libubacktrace.so (used by uclibc) appears to have a hard-coded path.
Where is libubacktrace.so actually installed?
Can you also do 'ldd /scratch/products/elsd/vmivme7805/linux-3.16.7_generic/output/host/usr/i686-buildroot-linux-uclibc/bin/ld' since the error might be from Linux being unable to run your cross-linker because it needs that .so, and if that's the case you might
resolve this by setting LD_LIBRARY_PATH to include the path where the libubacktrace.so is found.
However, when I created a softlink (yes, a cheat) so that it was found, the build failed next on readline;
which tells me, if I understand it, that SHRLIB_DEPLIB_DIRS += $(VMIVME)/staging/usr/lib didn't work
as expected. From Andrew's response to the 2013 query, the problem appears to be more
subtle; i.e. don't build a linux-x86 system on a linux-x86 system since it will always build for the host first.
In your case you appear to be cross-building for the target architecture linux-686 so it's not the same as your host architecture which I assume (with no evidence though) is probably linux-x86 or linux-x86_64.
I would suggest though that you try running 'make $EPICS_HOST_ARCH' from the top of your Base-3.14.12.7 tree. If this finishes without errors then you're good to look into what's wrong with the target build; if it fails though you do need to fix the host build
first.
I would greatly appreciate a better understanding of the problem and how to implement a remedy?
The application developer's guide does not appear (perhaps I'm missing something) to deal with
the situation presented by Buildroot's segregating build tools from target libraries, header files, etc.
Writing documentation for this level of configurability is pretty much impossible. I'm sorry that the Build chapter of the AppDevGuide is so out of date, but that's one of those things that nobody can easily find the time to do (Janet Anderson was working on
some updates but she retired some time back).
Come back with more evidence if the answers to the above don't help you find the issue.
- Andrew
--
Complexity comes for free, Simplicity you have to work for.
|
- Replies:
- Re: Fwd: cross-compiling (kind of) with Buildroot Pierrick M Hanlet via Tech-talk
- References:
- cross-compiling (kind of) with Buildroot Pierrick M Hanlet via Tech-talk
- Fwd: cross-compiling (kind of) with Buildroot Pierrick M Hanlet via Tech-talk
- Navigate by Date:
- Prev:
BNL Job Opening in NSLS-II Controls Anton Derbenev via Tech-talk
- Next:
RE: Accessing Elements of a Waveform Record Steiner, Mathias via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
<2019>
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Fwd: cross-compiling (kind of) with Buildroot Pierrick M Hanlet via Tech-talk
- Next:
Re: Fwd: cross-compiling (kind of) with Buildroot Pierrick M Hanlet via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
<2019>
2020
2021
2022
2023
2024
|
ANJ, 03 Jul 2019 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|