Hi Mark,
Thanks for your input.
Looking closely, indeed using 'STATIC_BUILD=YES' compiled EPICS code statically to my executable, leaving only the shared system libraries out. I guess I will build a virtual machine with my target's Linux distribution and compile from it, although a cross compiler would be neater =)
On Thu, Aug 2, 2012 at 11:18 AM, Mark Rivers <[email protected]> wrote:
You can make a static build, but that just means it does not use shareable libraries for the EPICS code, it still uses shareable libraries for the system libraries.
I ran into a very similar problem you are having yesterday, but mine was building on a newer Linux 64-bit system and trying to run on an older Linux 64-bit system. There
were problems with GLIBC, but also readline, libstdc++, etc.
I found that the easiest solution was to install EPICS base and the extensions I needed (e.g. medm, and also procServ) and build them on the older system. My actual application
I built on an even older Linux system, and it runs fine on the 2 newer systems. In my case the offending routine from GLIBC was memcpy(). That has been replaced with a new GLIBC version on recent Linux systems, so applications that use memcpy() won’t run
on older systems. Google search showed lots of people complaining about this, and the main workaround being to use memmove() instead.
In my opinion, this is one area where Windows does a much better job. I can tell the VS compiler to compile my code on a Windows 7 64-bit machine so that it will run on
any machine from Windows NT 4.0 and up (for example), and it works.
Mark
Hi
I'm back =) I'm having a problem deploying an IOC that I developed. I'm using a 64-bits Linux box as a host and I want to target a 32-bits Linux box. EPICS build system compiles my 32-bits executable just fine, but when I try to run it
in my 32-bits box (without any EPICS software whatsoever), I get errors. Specifically:
/lib/libc.so.6: version 'GLIBC_2.15' not found (required by lib/libCom.o)
Obviously, I have a version problem regarding the GLIBC: the host's version is 2.15 and the target's is 2.7. Investigating further on, the culprit is a symbol inside libCom.so:
$ objdump -T libCom.so | fgrep GLIBC_2.15
00000000 DF *UND* 00000000 GLIBC_2.15 __fdelt_chk
This is the only symbol that requires GLIBC 2.15. I looked at other symbols from libCom.so and from other EPICS shared objects and it seemed that they required versions below 2.5, which my target's GLIBC 2.7 could handle nicely.
Nevertheless, I looked around for solutions:
1. Upgrade GLIBC version in the target
The Linux distribution used does not provide an easy way to do so. The highest version I found easily available was 2.9. If all else fails, I might try this again. I would like to stick with this distribution, if possible.
2. Downgrade host's GLIBC
I'm using Ubuntu. It seems a long gap between 2.7 and 2.15 versions of GLIBC, so I couldn't find a package to just 'apt-get' it. Again, I might investigate this further if no other solution comes around.
3. Copy my host's GLIBC into my target
That was a long shot. Didn't work.
That is the option I like the best. Ideally I would want to just compile everything into an executable, drop that executable in my target box and then run it. Seems that a statically buily executable would nicely fulfill that purpose.
I really don't care about the file size.
I'm not familiar with the EPICS build system, so I tried to statically build my IOC by just adding 'LDFLAGS= -static' to my Makefile. This produced scary warnings and a million errors about the linker not finding pthread symbols.
Then I tried to put a 'STATIC_BUILD=YES' somewhere, but didn't know where exactly. I decided to put it in my application's configure/CONFIG_SITE. After I ran make again, the only difference I noted was the addition of '-Bstatic' to the
g++ flags.
According to the manual (man g++):
The options in this section are defined for all VxWorks targets. Options specific to the target hardware are listed with the other options for
These options are passed down to the linker. They are defined for compatibility with Diab.
Well, my target definitely isn't VxWorks...
So, finally, my questions:
Is it possible to make a static build of an IOC for x86 from a 64bits host? I searched EPICS documentation, but without much success...
Are there other solutions/alternatives? Maybe (most likely) I'm missing something here...
-- Bruno Seiva Martins
- Replies:
- Re: Cross-compilation, static build, etc Andrew Johnson
- Re: Cross-compilation, static build, etc Angus Gratton
- References:
- Cross-compilation, static build, etc Bruno Seiva Martins
- RE: Cross-compilation, static build, etc Mark Rivers
- Navigate by Date:
- Prev:
EPICS Support for Kashiyama Mu100/Mu300 Vacuum Pump? Boyes, Matthew
- Next:
Re: Cross-compilation, static build, etc Andrew Johnson
- 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:
RE: Cross-compilation, static build, etc Mark Rivers
- Next:
Re: Cross-compilation, static build, etc Andrew Johnson
- 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
|