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