yep.. there are different flavours of this thing...
I couldn't reproduce the bug after applying this:
https://git.enlightenment.org/core/efl.git/commit/?h=devs/jayji/kludge
Jean
On Mon, Mar 27, 2017 at 8:03 PM, Andrew Williams
wrote:
> Maybe I spoke too soon - on a
Maybe I spoke too soon - on a different Sierra box I get an error again,
albeit different to before:
[1]21907 illegal hardware instruction elementary_test
Which I think is this stack trace:
(lldb) bt
* thread #1: tid = 0x1ceba, 0x000100174227 dyld`_simple_salloc + 122,
queue =
Today I just updated on Sierra and it's not possible to reproduce the issue
as far as I can see...
\o/ (right?)
Andy
On Fri, 17 Mar 2017 at 13:35, Jean Guyomarc'h
wrote:
> Yep... that's one part of the problem, the eina_thread_join() of an evas
> thread worker...
>
Yep... that's one part of the problem, the eina_thread_join() of an evas
thread worker...
Sometimes it is eina_module_unload()...
Unfortunately, the debugger didn't tell me useful stuff. It seems to me
that the simple allocator gets corrupted at some point of the shutdown. But
without dynamic
switched from gdb to lldb and got something - does this help?
Process 21503 stopped
* thread #1: tid = 0xd66bd, 0x7fff957352ca
libsystem_platform.dylib`setjmp + 30, queue = 'com.apple.main-thread', stop
reason = EXC_BAD_ACCESS (code=1, address=0x78)
frame #0: 0x7fff957352ca
Try using lldb instead? Much better than gdb :D
When debugging in-tree, I use:
EFL_RUN_IN_TREE=1 glibtool --mode=execute lldb [PROG_ARGS]
Jean
On Fri, Mar 17, 2017 at 1:05 PM, Andrew Williams
wrote:
> Ok so I fixed that.
> But still get the same stack.
> So none of
Ok so I fixed that.
But still get the same stack.
So none of those ?? Calls are in efl...
Where to go from here?
A
On Thu, 16 Mar 2017 at 13:51, Jean Guyomarc'h
wrote:
> Mh.. CFLAGS='-O0 -g' when configuring? :D
>
>
> Jean
>
> On Thu, Mar 16, 2017 at 12:16 PM, Andrew
Mh.. CFLAGS='-O0 -g' when configuring? :D
Jean
On Thu, Mar 16, 2017 at 12:16 PM, Andrew Williams
wrote:
> Finally got gdb working on Sierra and I get this:
>
> (gdb) bt
> #0 0x000100049227 in ?? ()
> #1 0x00010006cda0 in ?? ()
> #2 0x00010006bea8 in ?? ()
Finally got gdb working on Sierra and I get this:
(gdb) bt
#0 0x000100049227 in ?? ()
#1 0x00010006cda0 in ?? ()
#2 0x00010006bea8 in ?? ()
#3 0x7fff5fbff640 in ?? ()
#4 0x000100026495 in ?? ()
#5 0x in ?? ()
sadpanda...
What do you think I missed?
> Apart from crashing on exit apps
I'm really puzzled about this... it seems to be sierra-specific, as I could
not reproduce it on el capitan. I fail to pinpoint the evil in the
machine... Valgrind not working on Sierra is not helping :'(
A __temporary__ """fix""" for the release could be not to
Perfect thanks. I pushed some improvements that made it better for repeat
runs and reset my local copy.
Bang it worked.
Apart from crashing on exit apps seem to be working nicely in OS X now :)
Great job!
Thanks,
Andy
On Tue, 14 Mar 2017 at 20:30, Jean Guyomarc'h
Hi Andrew,
after a brew update and another round of efler, everything seems to be fine.
[CLONE] efl
[BUILD] efl
[INST ] efl
[PULL ] efler
[BUILD] efler
[INST ] efler
[GUI ] Running efler application
I could compile efl without trouble, and could run the UI :)
Have you tried to re-run efler
Hi Jean,
Thanks for that. Can you update your brew repo and try again please? That
error should not occur if you are up to date.
As you discovered the bootstrap has some magic that understands if it is
already checked out or not which tripped you up.
I should improve it so that those cloning
I had some trouble using efler.
Since bootstrap.sh is not +x, I tried to run it with sh, and it failed
right away:
% sh bootstrap.sh
grep: /etc/*-release: No such file or directory
bootstrap.sh: line 145: /Users/Jean/.efler/efler/bootscripts/os/osx.sh: No
such file or directory
After peeking on
Good catch, thanks - but running it does not seem to fix the issue :(
On Mon, 13 Mar 2017 at 13:54 Jean Guyomarc'h
wrote:
> Mh... that's (kind of) a relief :)
>
> TLS_* stuff seems to be in openssl. It requires a specific handling via
> homebrew that I didn't found in
Mh... that's (kind of) a relief :)
TLS_* stuff seems to be in openssl. It requires a specific handling via
homebrew that I didn't found in
https://git.enlightenment.org/devs/ajwillia-ms/efler.git/tree/bootscripts/os/osx.sh
You need to:
brew link openssl --force
Otherwise, you may have problems
Hi Jean - I am using efler (should have said, sorry) which for OSX uses
these flags:
--disable-gstreamer --disable-gstreamer1 --disable-pulseaudio
--enable-i-really-know-what-i-am-doing-and-that-this-will-probably-break-things-and-i-will-fix-them-myself-and-send-patches-abb
Thanks,
Andrew
On
Just checking... did you follow
https://www.enlightenment.org/distros/osx-start ?
Are you using specific configure flags?
Jean
On Mon, Mar 13, 2017 at 11:47 AM, Andrew Williams
wrote:
> Running "glibtoolize" in the directory fixed it. I will try to do from
> clean again
Running "glibtoolize" in the directory fixed it. I will try to do from
clean again later.
Now I have the following compile error:
Undefined symbols for architecture x86_64:
"_TLSv1_1_client_method", referenced from:
_efl_net_ssl_ctx_setup in
Whaaat?! Worked fine two days ago! Did you start from a cleaned source
directory? (git clean -dfx)
Jean
On Mon, Mar 13, 2017 at 10:31 AM, Andrew Williams
wrote:
> It seems that building on Mac OS X is not currently working - any tips?
> This was working a week or two
It seems that building on Mac OS X is not currently working - any tips?
This was working a week or two back.
Thanks,
Andrew
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /Users/ajw/.efler/efl/missing
aclocal-1.15 -I m4
cd . && /bin/sh /Users/ajw/.efler/efl/missing automake-1.15 --gnu
21 matches
Mail list logo