You are not logged in.
For development I use an arch based box. I also like to do release builds from this box. The fun happens when the code needs to be able to run on say CentOS or Fedora Core 7 or any other older distro.
For a while I was using apgcc from the apbuild tools but that was a pain. I found the -UFORTIFY_SOURCE flag for gcc which seemed to take care of all the symbol compatibiliity problems I have. Unfortunately the latest problem problem has to do with the loader. Apparently /lib/ld-linux.so.2 has broken compatibility with these other systems (some running glibc-2.5, etc).
Any suggestions on how to deal with this?
Last edited by bnolsen (2013-10-23 14:44:16)
Offline
Fedora Core 7? Wow, that's ambitious. I'd suggest building in a virtual machine or chroot with the target system installed.
Offline
Fedora Core 7? Wow, that's ambitious. I'd suggest building in a virtual machine or chroot with the target system installed.
centos is probably worse. They're still on 2.6.18 as far as i can tell.
I wanted to avoid chroot/virtual machine (ran one of those for a while). The reason is that my current development build is the same as what is delivered. I don't want to lose that....having to deal with different compilers, libraries, etc can be a pain.
I'll also look into whether or not I can install a "glibc-compat" type package that could alleviate the loader.
Here's the telling part:
the new exectuble:
$ file <executable>
<executable>: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.27, dynamically linked (uses shared libs), for GNU/Linux 2.6.27
the old executable:
$ file <executable>
<executable>: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8
Okay....issue seems to be in the glibc PKGBUILD.
it has the line:
--enable-kernel=2.6.27 \
passed to glibc configuration.
Causes big time problems for creating compatible packages.
Last edited by bnolsen (2011-05-05 21:27:20)
Offline