Compiling the PNaCl version works, but still no luck with emscripten after switching from 64-bit clang to 32-bit clang :/
Time for lunch... Am Freitag, 10. Januar 2014 13:32:48 UTC+1 schrieb Floh: > > 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.
