Yes, it looks like this is a known issue from looking around vagrant and VirtualBox forums. Doing a proper "out-of-source" build, so that the whole compilation process runs outside the shared folder seems to work. Luckily this is trivial with cmake :)
-Floh. Am Freitag, 10. Januar 2014 16:19:31 UTC+1 schrieb jj: > > Oh wait, this reminds me of an issue with virtualbox folder sharing a long > time ago in a different project, where opening a file to truncate did not > work, but it always insisted on appending, and seeking in the file was > flaky as well. Trying completely outside virtualbox could be helpful in > seeing if it's really related to that. > On Jan 10, 2014 9:45 AM, "Floh" <[email protected] <javascript:>> wrote: > >> 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#L1428 and >>>>>>> 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 emscripten-discuss+unsubscribe >>>>>>>>>>> @googlegroups.com. >>>>>>>>>>> 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] <javascript:>. >> 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.
