Man, it's becoming stranger and stranger... On the Linux VM I can manually build archives that are broken, archives that work, depending on the object files that are contained. But the object files are all compiled with the same settings...
E.g. I can do a ~/clang-3.2/bin/llvm-ar cr test.a refcounted.cc.o rtti.cc.o Which produces a working lib, and use some other files from the same compile run to produce a broken lib! Are you guys using the 32-bit or 64-bit clang tools under Linux? I'll try next whether I have the same problems with the NaCl toolchain, these contain 32-bit clang tools while I'm currently trying the 64-bit precompiled version from http://llvm.org/releases/3.2/clang+llvm-3.2-x86_64-linux-ubuntu-12.04.tar.gz Cheers, -Floh. Am Freitag, 10. Januar 2014 12:45:33 UTC+1 schrieb Floh: > > Very strange, it's already the lib file before the copy that is broken in > the Linux VM... The lib which has been compiled on the host (OSX) works, I > can also look at this on the VM side. But the same lib created on the > Linux-VM is broken. The 2 files have exactly the same size, but internally > differ by few bytes. Especially the header looks different... > > Here's the working version, compiled on OSX: > > !<arch> > #_LLVM_SYM_TAB_#1389353161 501 20 644 135457 ` > > And here's the broken header, compiled on Linux: > > !<arch> > #_LLVM_SYM_TAB_#1389353331 1000 1000 644 135457 ` > > The clang versions are identical: > > OSX clang: > clang version 3.2 (tags/RELEASE_32/final) > Target: x86_64-apple-darwin13.0.0 > Thread model: posix > > OSX llvm-ar: > LLVM (http://llvm.org/): > LLVM version 3.2svn > Optimized build. > Default target: x86_64-apple-darwin13.0.0 > Host CPU: core-avx-i > > Linux clang: > clang version 3.2 (tags/RELEASE_32/final) > Target: x86_64-unknown-linux-gnu > Thread model: posix > > Linux llvm-ar: > LLVM (http://llvm.org/): > LLVM version 3.2svn > Optimized build. > Default target: x86_64-unknown-linux-gnu > Host CPU: core-avx-i > > > > Am Freitag, 10. Januar 2014 11:59:38 UTC+1 schrieb Floh: >> >> Argh you're right, thanks for the info that saved me going along the >> wrong track... >> >> I'm using os._exit() now and I'm seeing the temporary files in /tmp, so >> the copy to tmp seems to work as expected... I'll see what happens after >> that... >> >> PS: I'm seeing EM_SAVE_DIR only in one place in >> test_runner.py: tests/runner.py: save_dir = os.environ.get('EM_SAVE_DIR') >> >> Sure that works? >> >> -Floh. >> >> Am Freitag, 10. Januar 2014 11:35:33 UTC+1 schrieb jj: >>> >>> I suppose you added the sys.exit() call to early-out quit and avoid >>> temporary directory from being removed? I think the temp directory cleanup >>> is performed as an atexit handler, so it might be that sys.exit() still >>> calls those and therefore the files could have been there, but got still >>> erased. (just a hunch) So try double-check that to confirm. Another option >>> could be to sleep for a minute or so instead of sys.exit, if you want to >>> take a peek, or use EM_SAVE_DIR=1 environment variable to keep the files >>> around. >>> >>> Another debugging option to confirm that ar and bc files have not been >>> confused with a wrong suffix is to go to where llvm-ar is invoked in >>> emscripten, and after it fails, run Building.is_ar() and >>> Building.is_bitcode() on that file, see >>> https://github.com/kripken/emscripten/blob/master/tools/shared.py#L1428and >>> https://github.com/kripken/emscripten/blob/master/tools/shared.py#L1444. >>> That should give a definite answer as to what the files are. >>> >>> >>> 2014/1/10 Floh <[email protected]> >>> >>>> The culprit seem to be that shutil.copyfile() isn't working on my >>>> vagrant config. >>>> >>>> In emcc: >>>> >>>> elif file_ending.endswith(DYNAMICLIB_ENDINGS) or >>>> shared.Building.is_ar(input_file): >>>> logging.debug('copying library file: ' + input_file) >>>> temp_file = in_temp(uniquename(input_file)) >>>> shutil.copyfile(input_file, temp_file) >>>> sys.exit("BLLLLLLAAAAAAAA: from: " + input_file + " to: " + >>>> temp_file); >>>> temp_files.append(temp_file) >>>> >>>> the "sys.exit" is mine for debugging. After that statement exits, there >>>> is nothing in /tmp. The output is as follows: >>>> >>>> BLLLLLLAAAAAAAA: from: foundation/libfoundation.a to: >>>> /tmp/tmpYXfs1H/libfoundation_7.a >>>> >>>> I'll look deeper into the problem now. My config is: >>>> >>>> Host: OSX 10.9.1 >>>> VM: Ubuntu Precise 64-bit >>>> >>>> emscripten and all required tools are installed in the VM, but my >>>> project directory is shared with the host filesystem. >>>> >>>> Am Donnerstag, 9. Januar 2014 19:38:33 UTC+1 schrieb Floh: >>>> >>>>> Hmm could be, unfortunately that tmp file is gone after the build. The >>>>> actual libfoundation.a *is* an archive, at least it starts with something >>>>> like this: >>>>> >>>>> !<arch> >>>>> #_LLVM_SYM_TAB_#1389292218 1000 1000 644 135457 >>>>> >>>>> But the temp file which throws the error is gone. Wasn't there some >>>>> debug option where tmp files are not deleted after the build is finished? >>>>> >>>>> I'll try the vagrant setup mentioned in the Wiki tomorrow ( >>>>> https://github.com/rhelmer/emscripten-vagrant), and see if that works. >>>>> >>>>> Cheers, >>>>> -Floh. >>>>> >>>>> Am Donnerstag, 9. Januar 2014 18:57:44 UTC+1 schrieb jj: >>>>> >>>>>> This sounds like the file is not an archive file. Perhaps it's an >>>>>> LLVM bitcode (.bc) file instead with just an .a suffix? >>>>>> >>>>>> >>>>>> 2014/1/9 Floh <[email protected]> >>>>>> >>>>>>> I'm currently trying to setup a Linux dev-env for emscripten (Ubuntu >>>>>>> Precise 64-bit, running in Virtual Box on OSX), and I'm getting an >>>>>>> error >>>>>>> which I haven't seen yet on my OSX setup when linking: >>>>>>> >>>>>>> [218/218] Linking CXX shared library /home/vagrant/nebula3/bin/ >>>>>>> emsc/libworker_asmjs.js >>>>>>> /home/vagrant/clang-3.2/bin/llvm-ar: error loading >>>>>>> '/tmp/tmp1Nnzep/libfoundation_7.a': invalid file member signature! >>>>>>> /home/vagrant/clang-3.2/bin/llvm-ar: error loading >>>>>>> '/tmp/tmp1Nnzep/libZLIB_8.a': invalid file member signature! >>>>>>> >>>>>>> Anyone seen this error and knows what's the problem? >>>>>>> >>>>>>> Cheers, >>>>>>> -Floh. >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "emscripten-discuss" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>>> >>>>>> >>>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "emscripten-discuss" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
