[CMake] Compiling x86 executable on amd64
Mathieu Malaterre
mathieu.malaterre at gmail.com
Fri May 2 16:17:46 EDT 2008
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
More information about the CMake
mailing list