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]> 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 [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. > -- 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.
