[02:50] *** JohnTalen has joined #jsmess [02:51] Anyone familiar with Emscripten? It's pointing to native /usr/include. I'm getting the error:/usr/include/stdio.h:33:11: fatal error: 'stddef.h' file not found [02:51] it should be looking at emscripten includes. [02:53] hm it may be ac_includes_default. [03:15] i can read system files fine with emscripten. i suppose i'll have to go through all the samples until it breaks. [03:25] i was actually using this same configure file and file structure but debian, in it's infinite wisdom, decided to eat itself. no net drivers. so I installed another distro last night. [03:55] SketchCow: To get a good idea on the status of v86 try removing the dial up adapter. you will see it restart/reboot. [03:56] or rather,.. you won't. :) [05:17] I am contemplating compiling not just llvm but everything else from scratch if I don't get online answers. [05:17] if you install emscripten using emsdk, that's exactly what it does [05:17] and that's what you should do, yes [05:18] you want the entire toolchain compiled at the same time, to make sure you get versions that are in sync [05:18] having other versions installed only complicates things [05:27] bai: i had to compile llvm 4 to install LLVMgold.so. [05:27] i need -flto. i'm suprised you didn't need it. [05:27] bai: ^ [05:30] SketchCow: http://pdp11.aiju.de/ [05:35] dunno, guess mame and dosbox don't require that option [05:35] have you seen this already? https://github.com/kripken/emscripten-fastcomp/blob/master/docs/GoldPlugin.rst [05:38] yes. i have all that working. [05:38] That's an old issue. [05:38] It only works now because I manually recompiled LLVM4.0. [05:39] at the moment it's looking at native include headers, partially and not correctly. [05:39] I don't want it to look at *any* native headers. [05:39] I have this configure script working 2 days ago and then it just changed. [05:39] I reset the emscripten cache so it's not that and it's not the distro because I reinstalled everything last night. [05:47] did you set up all the appropriate emscripten environment variables, including path? [05:49] yes, activated latest, sourced the script file. [05:49] I also set the vars ala https://gbalats.github.io/2015/12/10/compiling-autotooled-projects-to-LLVM-bitcode.html [05:59] anything else? [06:07] not that I can think of, but it sounds like maybe vice uses some compile-time options which mame and dosbox didn't [06:08] perhaps. but I had this specific configure working with compiling vice using emscripten. [06:08] i'm not sure what changed. [06:10] i was to the point just before using emcc to link into js files. [06:10] yeah, that's why I was wondering if it was some missing environment vars, I've definitely been in exactly this sort of scenario before where I had multiple versions installed and things were pointing to inconsistent locations [06:11] bai: i just installed this configuration last night. [06:11] then i installed g++ 6.2. installed emscripten, then compiled llvm4.0 for LLVMgold.so. [06:11] how the heck did you get LLVMgold? [06:11] Windoze? [06:14] I have never had to deal with that before. I've always compiled on ubuntu systems [06:16] bai: you don't use the '-flto' compiler option? [06:16] not to my knowledge [06:23] I took out all those options. still gets to that error. [06:24] bai: of course only me and you working on the holidays! :) [07:13] bai: I can read linux text files from the emscipten virtual file system fine in the browser. [07:14] i think the problem may be the configure script. Something vital is missing. But again, i was using this to compile before. [08:22] *** Swizzle_ has quit IRC (Quit: Leaving) [15:47] *** jvilk_ has quit IRC (Ping timeout: 260 seconds) [20:09] *** godane has quit IRC (ny.us.hub hub.efnet.us) [20:09] *** devesine has quit IRC (ny.us.hub hub.efnet.us) [20:09] *** gsathya has quit IRC (ny.us.hub hub.efnet.us) [20:09] *** SketchCow has quit IRC (ny.us.hub hub.efnet.us) [20:09] *** zino has quit IRC (ny.us.hub hub.efnet.us) [20:09] *** arkiver has quit IRC (ny.us.hub hub.efnet.us) [20:09] *** bai has quit IRC (ny.us.hub hub.efnet.us) [20:09] *** datajerk has quit IRC (ny.us.hub hub.efnet.us) [20:09] *** Lord_Nigh has quit IRC (ny.us.hub hub.efnet.us) [20:52] *** datajerk has joined #jsmess [20:52] *** godane has joined #jsmess [20:52] *** gsathya has joined #jsmess [20:52] *** devesine has joined #jsmess [20:52] *** bai has joined #jsmess [20:52] *** Lord_Nigh has joined #jsmess [20:52] *** SketchCow has joined #jsmess [20:52] *** zino has joined #jsmess [20:52] *** arkiver has joined #jsmess [20:52] *** hub.efnet.us sets mode: +o arkiver [21:13] *** bwn has quit IRC (Ping timeout: 268 seconds) [21:33] *** bwn has joined #jsmess [22:30] bai: have you used ar / llvm-ar / emar with emscripten? [22:30] btw- I got past the error, i use emcc instead of clang. [22:32] I mean if I'm working with ar or emcc directly that normally means I'm off in egregious-hack land, is the thing [22:33] like I took a wrong turn at albuquerque [22:33] hehe. [22:33] it says my ar is too old. [22:33] normally if those are giving me problems, it's because something is wrong with my environment and it's calling the wrong version of the tools, not the ones which emscripten expects [22:34] I have tried export AR=emar AR=llvm-ar to no different avail. [22:34] i even tried the test the configure uses to generate that error message. it works then. [22:35] it works if I type the tests out. [22:35] that is. [22:35] you're using "emconfigure ./configure" when building, right? not running configure directly? [22:35] emconfigure ./configure --enable-debug -enable-sdlui --with-sdlsound --without-residfp --without-resid CC=emcc CXX=emcc [22:36] seems reasonable yeah [22:37] emar: ['/home/john/Downloads/2017/dev/emularity/emscripten/emsdk/emsdk-portable/emscripten/1.37.14/emar', 'x', 'libvicetest.a'] ==> ['/home/john/Downloads/2017/dev/emularity/emscripten/emsdk/emsdk-portable/clang/e1.37.14_64bit/llvm-ar', 'x', 'libvicetest.a'] [22:37] yes [22:38] configure: error: ar is too old, upgrade your ar [22:38] sounds like something that could be filed as a bug against emscripten [22:39] 'if test -f some_long_object_name.o; then' is the actual script determiner in this case. [22:41] DFJustin: thanks. [22:44] hm, the determiner is /usr/bin/test. [22:44] so i'm not so sure about that. [22:46] test works correctly. [22:48] ha got it! [22:48] instead of producing some_long.so it produces some_long_d380e396.o [22:48] weird [22:49] so emar is weird like that! :) [22:50] you're right DFJustin! [22:50] DFJustin++; [22:53] using llvm-ar instead and WORKING! [22:56] just gotta install SDL-dev stuff on this unix box. [22:56] i love saying that.. 'unix box'. [22:56] whewhoo. finally getting somewhere. [22:58] yes em-ar intentionally adds a checksum to the filename to avoid problems when projects have multiple .o files with the same name (which happened in mame) [23:00] without that you're likely to get missing symbol issues as it only ends up using one of the identically-named files [23:03] so I guess the configure script needs tweaking [23:23] DFJustin: The configure script was done. I used llvm-ar instead of emar. llvm-ar works as intended. I just have to work on the make process. but progress! [23:33] have you guys used sdl1.2 with emscripten? [23:36] yeah early builds of jsmess used sdl1.2 (or maybe 1.3, I forget)...emscripten handles sdl1.2 very differently than 2.x [23:37] everything SDL is yes, except for: checking SDL/SDL.h presence... no [23:37] configure: WARNING: SDL/SDL.h: accepted by the compiler, rejected by the preprocessor [23:37] i want to use 1.2 for now because that is what vice.js uses. [23:37] emscripten emulates sdl1.2 purely in js, they override all the functions with library equivalents in https://github.com/kripken/emscripten/blob/master/src/library_sdl.js [23:37] then i will upgrade. [23:38] ok [23:38] whereas sdl2 uses emscripten's ports system, which just pulls down the release version of sdl2 from source and builds it for you [23:38] bai: how should I go about this then?? [23:39] generally speaking the sdl1.2 support was solid enough, if the app was written for 1.2 and doesn't have a 2.0 codepath then just stick with that [23:39] but if it's a matter of a compile-time flag to switch between 1.2 and 2.0, go with 2.0 [23:40] okay. but how do I employ sdl 1.2 into the configure or do I have to? [23:41] emcc needs to be configured to receive the -s USE_SDL=1 argument, I believe [23:41] ah ok. [23:41] is that a macro? [23:41] trying to find the docs about it [23:42] it's an emscripten setting - I think https://github.com/kripken/emscripten/blob/master/src/settings.js is the best documentation of all the various settings emscripten supports [23:43] sdl-related settings: https://github.com/kripken/emscripten/blob/master/src/settings.js#L692-L697 [23:44] looks like 1.2 not 1.3 but I think they should be compatible [23:45] ha! found someone years ago with the same problem with this vice. [23:45] https://github.com/kripken/emscripten/blob/master/src/settings.js#L692-L697 [23:46] looks like we found the same page. [23:47] hm, no just a copy error. [23:48] oops just realized I said the versions backwards, it's 1.3 not 1.2 [23:50] i just need to get this configure script to talk to the myriad of Makefiles it creates. [23:56] bai: does emscripten have a directory you can install include files so that conifgure passes it's test? [23:58] it does have a directory which the ports install their includes into yes...but I think generally it's better to handle that by adding special -I rules when the compile target is emscripten [23:59] ah, tell me this. what is the preprocessor for emscripten and do i have to manually set it? [23:59] i tried -I/usr/include/SDL.