On Mon, 2013-06-03 at 13:37 -0700, Kip Warner wrote: > Another thing, I see the the libstdc++.so.6 and libgcc_s.so.1 removed > from its dependencies according to objdump, but I did note the addition > of a new one, ld-linux-x86-64.so.2. Do you think that will be a problem? I can't think of any reason why adding those flags would cause this to happen. Indeed, I can't think of any reason why ld-linux.so would NOT be linked with your application before these flags were added. I would have thought that any executable that had any dynamic libraries linked at all would need this (it's the runtime linker). Are you sure that library didn't used to exist in the ldd output? If so, were you linking your executable statically (no shared libs) before? Anyway, seeing that library doesn't bother me. > I wonder if I could do this for a GNU/Linux i386 binary and amd64, and a > w32 binary via mingw sysroot, if such a thing is possible. It is certainly possible to create a cross-compilation environment to build Windows/mingw output on a Linux system; indeed it's becoming a very popular way of handling Windows targets. Some google searching will lead you to many examples and write-ups; I don't have anything handy that I've tried and can attest to unfortunately. However, it WON'T be as simple as you describe above. Just having a different sysroot won't be enough: you'll have to actually create a separate cross-compiler toolchain as well. That's because all the Linux-based distributions use the same basic executable layout, calling structure, etc. (ELF). So, the only real difference from a compiler standpoint between Red Hat, Debian, etc. are the versions of the various shared libraries that are installed. Windows, on the other hand uses an entirely different layout for its executables and libraries. It's far more than just some library version differences: you need a whole different compiler. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
