Hello.
On 01/09/2018 07:50 AM, Carsten Haitzler wrote: > On Mon, 8 Jan 2018 09:38:38 +0100 Stefan Schmidt <ste...@osg.samsung.com> > said: > > i wish i has an osx vm to test in... i did test windows, freebsd builds as > well > as linux. Yeah, its a pain to work with. Marcel asked for the same for his meson work. >From what I understand you need to run such a vm also on Apple hardware by >license. (Makes one wonder why we care about support for them when they do not for supporting developers) Does your freebsd runs fine for the build edje_cc as well? It could be the closest you have to osx. Sadly all I can offer here is the Travis build which does not allow shell access as far as I know. What Marcel did was getting ssh access to a osx machine from netstar to do its testing. > > where is the break? i do see: > > Ecore sig handler NOT called from sigwatcher thread > > this is kind of an "error marker" where signal handlers are being called on > other threads. only on windows is the sigmask stuff disabled. the signals are > masked out on all threads EXCEPT the sigwatcher thread... technically this > isn't > really necessary given the way i did things with pipes... i can probably even > remove the watcher and just have signals called anywhere as write()'s to the > pipe should be atomic/mt/signal safe (for the small amount of data that is > written). > > but where is the build break? i see no error. oh wait. need to look at the raw > log. > > edje_cc: Critical. Unable to open temp file "(null)" for script compilation. > > No output has been received in the last 10m0s, this potentially indicates a > stalled build or something wrong with the build itself. Check the details on > how to adjust your build configuration on: > https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received > > that? edje_cc is hanging? Yes, this build error was not a compilation break but our own build edje_cc not working when being used later in the build. > why? the changes still use signal handlers and every > signal is write()n down a pipe that the main loop reads and thus handles as > events... ? unless a write() went missing ... which i doubt, or a signal > handler wasn't called for a sigchld... but the signal handlers are not > enabled/disabled or blocked/unblocked as things run... as i said - can remove > the thread but i doubt that makes any difference. it shouldn't. To be honest I have no clue about the different behaviors of thread handling in osx. I will try a revert of your patches in a branch to get Travis building them (Travis and thus osx builds are now being done for all branches not only master. It only gets triggered after the github sync each full hour, though). That should at least give us an idea if latest master works again with them reverted. Not really debugged, but at least verified that it is one of these patches and not something else. regards Stefan Schmidt ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
