Ok, looks like it is the folder sharing :/ Copying the project into a non-shared folder in the VM seems to work. I'll try updating VirtualBox and vagrant, and then find out more about his.
Compiling is also infinitely faster in non-shared folders. -Floh. Am Freitag, 10. Januar 2014 13:55:40 UTC+1 schrieb Floh: > > 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.
