On Wed, 2011-03-30 at 14:33 -0400, Denniston, Todd A CIV NAVSURFWARCENDIV Crane wrote: > > I've tried the -m32 flag, along with "CC=gcc34" to actually cause it > to > > use the compat compiler instead of the new one. The build process > > produces a lot of warnings that may or may not have been there before, > > then bails out with: > > > > make: *** No rule to make target `/usr/lib/gcc/i386-redhat- > > linux/3.4.6/include/stdarg.h', needed by `hostcom.o'. Stop. > > > > On the old server, which I have limited access to, that file is owned > > by > > the compat-gcc-34 package. And the 64-bit version of this package is > > installed on the new server, so the directory is x86_64-redhat-linux > > instead of i386-redhat-linux. > > > > Unfortunately, from what I see, the x86_64 yum repos only offer an > x86_64 version of compat-gcc-34. > compat-gcc-34.x86_64 has > /usr/lib/gcc/x86_64-redhat-linux/3.4.6/include/stdarg.h > > *Perhaps* this (that it does not provide the *gcc/i386-* include tree, > or that the i386 version is not also in the x86_64 repo) can be seen as > a bug in the x86_64 package, to report upstream??? Ugh. These are not the kind of words I relish hearing. > The error above looks like either by specifying the -m32 flag or by a > hard code in either hostcom.c (or one of its included files) the 32bit > version of the stdarg.h header is included instead of the available > x86_64 version. I'm sure it's not hard coded in hostcom.c. I'm not even sure why system header files are being included here. The projects are firmwares embedded systems that don't include libc at all. But I'm not, in this case, qualified to speculate on the reason or even the propriety of it. > Seeing as you have source I would first try to compile it as 64bit and > if the build works, then test heavily to verify the functionality. > The drawback is that we have seen several open source projects*** with > issues while they ported their software from 32 to 64. Perhaps there is > a URL of Frequently seen 32 to 64 bit porting problems, that you could > look at to be aware of the kinds of errors others have seen. > > Again my first option would be try to go native (x86_64) and see if it > works correctly. Unfortunately, the resulting binary is loaded and run on a 32-bit embedded system that bears almost no resemblance to a PC except that the processor is x86 compatible. Compiling as 64-bit would be a serious challenge and testing the output would be impossible. > Another option to keep from reinstalling, granted only slightly easier > than reinstalling, is setup a KVM or XEN virtual machine on the server > and install enough of the 32 bit CentOS to allow you to compile the > source in a 32 bit environment and then install the binary onto the 64 > bit system and make sure all the needed 32bit libs are available. You > might even be able to fallback to running just that application in the > VM while running everything else in the bare metal, granted then you get > twice the effort for securing the OS (it IS another machine) and keeping > the OS up to date. *sigh* I can see that's where I'm headed. I might as well give in and start the process of installing the 32-bit OS and build environment on another machine now. The boss is not going to be happy about this. > Third option may be as others suggested, try to use mock to build the > 32bit binary using the 64bit system. You would still need to make sure > all the needed 32bit libs are available on the 64bit machine. [I have > not used mock yet so I am unsure of the ability for it to provide the > cross environment needed.] I've never done mock, so I don't think I will be going that direction. Not while I have half the company breathing over my shoulder asking when the build system will be running again. Does anybody know how to set up KVM on a headless, unattended server to run a virtual machine automatically on boot? I've only ever used it on my desktop with pointy-clicky tools like virt-manager. Even still, I usually use VirtualBox for virtual machines on my desktop. -Alan