On Wed, Oct 26, 2016 at 6:41 AM, Vincent Torri <[email protected]> wrote: > On Wed, Oct 26, 2016 at 10:34 AM, Andrii Kroitor <[email protected]> > wrote: >> Hello, Adrien. >> >> It's nice to meet you here. >> >> On 26.10.16 08:50, Adrien Nader wrote: >>> [...] >>>>> Should these packages be updated and uploaded manually? >>>> If the path with win builds does not work out we could host the windows >>>> binaries next to our source tarballs. Only for releases thought. >>> Writing and improving the package manager's GUI took time off the >>> packaging itself and has delayed the current release a lot. >> Could you share some estimation on release date, please? Have you changed >> or updated something in cross builds part? >> I have tried to setup win-builds cross compilation on few different >> Linux systems, >> but it was unsuccessful. Are your current scripts in public access >> somewhere? >>> But that actually doesn't matter much. It's supposed to be possible to >>> base on win-builds and build other versions or other packages and I >>> don't see why that couldn't apply to the EFLs. >>> >>> However I'm not sure I understand some of things done in that git >>> repository. I've only taken a cursory look at it and can't comment much >>> but I've been more than surprised to see a pthread.h file copied there >>> and that it came from pthreads-win32 which, I think(*), is >>> ABI-incompatible while winpthreasd doesn't have that issue (everyone and >>> their mothers assume pthread_t is an int like on linux). >>> >>> (*) maybe I've fixed the only occurrence of it a couple years ago, or >>> maybe not, I don't know anymore, but somehow I doubt it >> That file came from winpthreads-v3.3.0-2-x86_64-w64-mingw32.txz package >> from winbuilds. >> I've only added one explicit cast to bypass compilation error of >> upstream EFL. >> Problem is with pthread_cleanup_pop macro: >> >> #define pthread_cleanup_pop(E)\ >> (*pthread_getclean() = _pthread_cup.next, >> (E?_pthread_cup.func((pthread_once_t *)_pthread_cup.arg):0));} >> >> It works fine in C code, but in case of C++ last 0 should be casted to >> (void) > > gustavo introduced that error, i've mentioned this bug to him. Instead > of adding a pthread implementation with potential problems with ABI, > fix really the problems in the EFL
what? i don't follow you here. AFAIU I've followed all advice, checked the pthread wrapper you mentioned, it said it was working, including they had unit tests for what we used. as for pthread_cleanup_pop(), Adrien are you sure that's the same code for C and C++? Libc has 2 completely different code path for them. -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
