Hi all,

I wonder if there is an easy way to accomplish the following:
I made a tool and part of it needs to be compiled.
It would be easy if I can automate compilation for multiple platforms (x86 / x86_64 / RHEL / SLES / Ubuntu).
Is there a way to do this automated on a single host?
Or should I set up an os for each distro?

Anyone has good references on how to do something like this?

Also is there a way to generate RPM and deb files also on the same host without having to edit the meta files each time a version changes?
I did put something together but it is not really clean.

You want builds for
x86 / x86_64 / RHEL / SLES / Ubuntu

I guess, it's mean

RHEL x86 and x86_64
SLES x86 and x86_64
Ubuntu x86 and x86_64

Correct ?

OK, x86/x86_64

At least for RHEL when you build on x86_64 you can get binaries both for x86 and x86_64:
once run make as usual for creating x86_64 binary and another time pass flag -m32 to gcc. Then x86 binary will be created

RHEL/SLES/Ubuntu

You can build you executable on, say, RHEL and then pray/test that it will work on the others distributions.

Or your can install each one of the distribution in the VM (qemu, virtualbox, vmware, even physical box - it's doesn't matter),
set passwordless ssh access to each of them, and write a simple script to run make on each vm.

While build on all hosts will be automatic it will require significant effort to prepare all this boxes. And if you want to support a number of RHEL/SLES/Ubuntu version situation will be even worse

Providing binaries for a number of distribution/version required
a lot of resources.

You can consider creating portable executable instead.
It was recenly discussed in this thread:

http://www.linuxquestions.org/questi...the-f-|-801897

Yes that is indeed what I want to do.
I have my sources compiled on a Ubuntu machine. I will look what ldd gives on each platform and based on that see how I can make it "cross platform".
Thanks for the link, I will look into it.

I now created some scripts to create a deb and rpm file.
It is mostly automated. I knew there were some issues in the past with Suse.

If you have rpm (or deb) package you can use alien to convert from rpm to deb or back. But if you already wrote naitve scipts to build both rpm and deb, may bi's simpler to have it this way

Valery Reznic: I used alien in the first place. Then I used that spec file and wrote a script to automatically update the spec file and rpmbuild from that.
But this is not actually my biggest concern.

I am trying to get a version of my tool running in both x86_64. I have seen that on all 32bit linux where I testing with one compilation of the program does the trick.
However for 64 bit machines this binary does not work unless you do some modifications.
What is possible is to install the necessary 32 bit libraries: sudo apt-get install ia32-libs
And install a 32 bit version of libgnome-keyring.so.0 (this is possible using getlibs).
Downside of this it is more a "workaround" than a fix(and I like fixes, not workarounds).

Made quickly a VM with Ubuntu 64 bit.
I tried to compile it using the -m32 option:
It seems that it still tries to search in the 64 bit libraries directory (/usr/lib/) instead of /usr/lib32.
The file is there in /usr/lib32.
Am I doing something wrong?
I don't have alot of experience in compiling.

I don't see installing 32bit libraries as workaround.

Fedora 64 bit installed both 64 and 32 bit libraries.
So on Fedora it's "just work".

Ubuntu choose another approach - go pure 64 bit and leave to the user to worry about installing 32 bit libraries. But the point 32 bit executable needed 32 bit libraries. No way around it. And IMO it doesn't matter who install those libraries - system installer or you - it's fix, not workaround.

About your compilation error in Ubuntu 64 bit VM - it's looks like you didn't installed 32 bit libraries there.

What I want to do now is compile from the 64 bit and with the -m32 option I should be able to get a 32 bit executable.
I do have 32 bit libs installed (got ia32libs and one other with getlibs (libgnome-keyring)).
I have a /usr/lib32, ... with the actual file in it.
Or do I need some other packages?

The problem is your 'pkg_config'
It produces output for 64-bit build.
In order to get output for 32-bit build you have to run it as

PKG_CONFIG_PATH should be path with configs for 32 bit build.
On my Fedora system config for 64 bit is /usr/lib64/pkgconfig
for 32 bit -/usr/lib/pkgconfig

On Ubuntu, I GUESS, for 64 bit /usr/lib/pkgconfig, for 32 bit /usr/lib32/pkgconfig
For more info see pkg-config

1 members found this post helpful.

I tried this with /usr/lib32/pkgconfig (I checked this and this seems to be the correct path).
However it still fails.

It seems that in the /usr/lib/pkgconfig there are alot of *.pc file.
In /usr/lib32/pkgconfig I see only a few. And most important, in the first location I find gnome-keyring.pc while I do not find it in the /usr/lib32/pkg-config directory.
Can I just copy these over? Or do I actually need to install an extra package?
Maybe the 32bit lib file downloaded by getlibs is not enough to compile against it.

You helped me alot Valery Reznic! Thanks alot!

You can't just copy gnome-keyring.pc from /usr/lib/pkgconfig, it will not help (OK, you can try and see yourself

What you need is install development package for getlibc (getlibc-devel, or something like that)

Or on the second thought you can copy gnome-keyring.pc from /usr/lib/pkgconfig but you'll need to adjust it to point to the 32-bit libraries instead of 64. But it's a hack, Better install package

You are welcome

I tried first to copy the file and edit it to point to the lib in /usr/lib32 (I wanted to try it just to be sure if it would work or not).
This did not work I still got the same error.

After that I was pretty sure I needed a dev version for the library.
Did:
getlibs libgnome-keyring-0
And it installed a devel lib.
Now I could compile and all seems well

The only thing I wonder is the difference between those 2 libs. Does a dev lib has "symbols" and a non dev lib no "symbols"? (as I said before, I'm a noob in compiling C(++)-apps)

So you fixed my problem... thanks again!

No, the difference is not symbol/no symbol.

Usually lib package has a shared libraries with names in the form
libFOO.version.so

Development package has files (usually just links) with names in the form
libFOO.so, that points to the actual shared libraries libFOO.version.so
Also development package includes header files and sometimes static libraries libFOO.a