Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20192020  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  <20192020 
<== Date ==> <== Thread ==>

Subject: Re: Fwd: cross-compiling (kind of) with Buildroot
From: Pierrick M Hanlet via Tech-talk <tech-talk@aps.anl.gov>
To: "Johnson, Andrew N." <anj@anl.gov>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Wed, 3 Jul 2019 16:51:07 +0000
Hi Andrew,
The host build was successful, and yes, my host is linux-x86_64.

I reverted the ./base/configure/CONFIG.CrossCommon file and now when attempting
to build the target (I assume that's what I'm doing because my gcc and g++ are from
one of my Buildroot directories rather than /usr/bin), compilation fails at readline/readline.h.

The remaining responses are inline:
Thank you,
Pierrick

On 7/2/19 4:45 PM, Johnson, Andrew N. via Tech-talk wrote:
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?
Yes, the next quotation is the follows immediately from the last one.

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?
This one was resolved.

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.
hanlet:~/platforms/vmivme7805/epicsDEV/base> ldd /scratch/products/elsd/vmivme7805/linux-3.16.7_generic/output/host/usr/i686-buildroot-linux-uclibc/bin/ld
    linux-vdso.so.1 =>  (0x00007ffeca51f000)
    libz.so.1 => /home/jdiamond/workspace/ees-buildroot/output/host/usr/lib/libz.so.1 (0x00007f7372fc6000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f7372dc2000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f73729f5000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f73731dc000)



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.
Success.

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.

-- 
Pierrick Hanlet
Fermi National Accelerator
Accelerator Front End Controls
+1-630-840-5555 -- lab
+1-312-687-4980 -- mobile

"Whether you think you can or think you can't, you're right" -- Henry Ford

Replies:
Re: Fwd: cross-compiling (kind of) with Buildroot Johnson, Andrew N. 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
Re: Fwd: cross-compiling (kind of) with Buildroot Johnson, Andrew N. via Tech-talk

Navigate by Date:
Prev: Re: [EXTERNAL] Beckhoff BK9000 support survey Wallace, Alex via Tech-talk
Next: Re: Fwd: cross-compiling (kind of) with Buildroot Johnson, Andrew N. 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  <20192020 
Navigate by Thread:
Prev: Re: Fwd: cross-compiling (kind of) with Buildroot Johnson, Andrew N. via Tech-talk
Next: Re: Fwd: cross-compiling (kind of) with Buildroot Johnson, Andrew N. 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  <20192020 
ANJ, 03 Jul 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·