[CMake] Compiling x86 executable on amd64

[Mathieu Malaterre]

John,

On Fri, May 2, 2008 at 9:07 PM, John Doe <ufnoise at gmail.com> wrote:
> Mathieu,
>
>  It is perfectly ok to redistribute libstdc++.  You put it in your
>  directory tree, not in the standard system location.
>
>  Setting LD_LIBRARY_PATH to the directory of your libstdc++ allows only
>  applications started in that shell environment to find it.  You can
>  use a wrapper script to set this environment variable and exec your
>  binary.  This is the same stuff that firefox has been doing for years
>  for all of their dependencies.

This is way too complex, at least for me. You have to create a script
that will call your real binary. If I had it from scratch, I might
have taken this solution. But again I am not trying some crazy cross
compilation thingy, just simple x86 instruction on a x86_64 machine
(with multilib!).

>  Use ldd on your binary to determine which shared libraries you link
>  against.  Use ldd on the shared libraries to determine the shared
>  libraries they link against.  Make sure that the appropriate libraries
>  are redistributed with your app.  Of course certain one's cannot be
>  redistributed since they are directly linked against your particular
>  kernel and would be useless to your customer.

Very hard to implement at least in cmake. At least way too much time consuming.

>  Statically link as much as you can.  The p4 client works fine on my
>  gentoo box.  So does the intel compiler the last time I checked.  See
>  what libraries they redistribute.

?
I hate static lib, start creating a bunch of exectutable and your
achive grows exponentially. I think it gets even worse with cmake, as
it try to pull dependencie of dependeie (not verified).

>  To get around this issue, many vendors say which distributions are
>  supported by their application so they don't have to build and support
>  every linux distribution out there.

cmake binaries works without all what you describe AFAIK.

>  Creating a chroot jail (or using vmware) are other alternatives.

I was trying to be ironical for the vmware thingy. I certainly do not
want to re-install a complete system for a simple compiler flag. But I
can understand that chroot is a pretty nice solution for running
dashboard (then you are sure to reproduce exactly target system of
your users)

>  How is trying to help you redistribute linux applications make me a
>  Microsoft spy?

Reading your post, it looked like a very complex solution, while I was
only looking for simple stuff :)

> How is insulting your customers by saying they don't
>  know how to compile things not make you a Microsoft spy?

Most people on Win32 system do not know, do not need a compiler to
quickly try a freeware. Of course when you know what cmake is, what
out of source is, where gcc is, what g++ version you are using, then
yes you can compiler with all your crazy compilation flag.
As a side note, according to sf.net stats, I have more users download
the binaries, than the source code... well it might only means there
is more win32 users with no compiler outta there :)

>  The hard reality is that it isn't easy to guarantee compatibility
>  across all of your applications.
>
>  How is g++ 4.3 that much of a step up from g++ 3.4?  Why not use the
>  intel compiler or the one from the portland group?

I am happy with g++. g++ 3.4 will solve part of my issue since it is
garantee to use the old ABI of the glibc, which is what I am trying to
do.
So again I perfectly understand my binaries will not run on old
system, where gcc 3.3 was the default, but I am pretty sure that 90%
of people have now g++-4.0 or above. For other, then yes, they'll
better learn about cmake/g++ :)

I cannot test right now, but apparently the compile flag I was looking
for is simply '-m32', ref:

http://gentoo-wiki.com/TIP_AMD64-x86-distcc

Now I am pretty sure that g++-3.4 + -m32 will allow me to produce x86
executable that anyone can execute, out of the box (maybe not some old
system using pre gcc 3.4 system where C++ ABI was different, but I'll
assume they'll tends to disapear as time goes).

Thanks anyway
-- 
Mathieu