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.
