On Fri, May 2, 2008 at 10:17 PM, Mathieu Malaterre <[EMAIL PROTECTED]> wrote: > John, > > > On Fri, May 2, 2008 at 9:07 PM, John Doe <[EMAIL PROTECTED]> 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 _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
