[CMake] Compiling x86 executable on amd64

[Mathieu Malaterre]

On Fri, May 2, 2008 at 10:17 PM, Mathieu Malaterre
<mathieu.malaterre at gmail.com> wrote:
> 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).

I finally found a link:

http://trac.autopackage.org/wiki/GlibcVersionsOfDifferentLinuxDistributions

From

http://groups.google.com/group/gnu.g++.help/msg/32c0df4f11ff018a

I'll try that on monday.


-- 
Mathieu