github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 25 June 2013.
01:06 Guest1337 joined 01:30 FROGGS joined 02:05 benabik joined 02:50 JimmyZ_ joined 03:46 Guest1337 joined
JimmyZ [A 03:49
05:39 FROGGS[mobile] joined 10:05 woosley1 joined 12:28 _ilbot joined
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
12:35 birdwindupbird joined 13:11 woosley1 joined 13:24 FROGGS[mobile] joined 13:40 FROGGS[mobile] joined
dalek arVM: 9920029 | (Geoffrey Broadwell)++ | src/core/oplist:
Snapshot of bigint op additions to src/core/oplist
 14:36
arVM: c421703 | (Geoffrey Broadwell)++ | src/core/interp.c:
Merge branch 'master' into add-bigint-ops

Cope with nqp::locallifetime.
jnthn Just merged japhb++'s earlier bigint work. 14:37
14:37 dalek joined
JimmyZ \\o/, japhb++ 14:38
jnthn JimmyZ: Will get to your container branch shortly... 14:40
JimmyZ jnthn: thanks :P 14:44
jnthn Moar's nqp-cc now passes nqptest against latest nqp again.
nwc10 if MoarVM is prepared to bundle APR, should it not also bundle libuuid? 15:52
jnthn Apart from we're gonna move to libuv.
nwc10 (or, more elegantly, force the configure/link *not* to detect uuid.h)
oh, it's autoconf. mahahaha(bias)hahahaa 15:53
jnthn ;)
nwc10 because, as best I can work out, libuuid is *optional* for APR
jnthn We certainly ain't using that feature of APR
Wonder if you can configure to avoid it at all 15:54
nwc10 mmm, yes. 15:55
FROGGS that would save us a lot of pain 15:56
I believe there were more than 5 commits/PRs that "make libuuid work"
benabik Can't we just pass --no-uuid to APR or something? 15:58
jnthn Yes, if it offers that
benabik I suppose that question was more "shouldn't APR have a --no-uuid" option? ;-) 15:59
nwc10 it's autoconf 16:00
if it exists it will be spelled differnetly
and it's not in --help
also, and this is an opinion, I see *no* benefit to using a shared object for a bundled library 16:02
it's just making work
that shared library in the private tree (not even installed yet) is not used by anything other than the moarvm executable 16:03
so
1) LD_LIBRARY_PATH or however the OS names that variable has to be set
2) the dynamic linker does work at runtime 16:04
but there's no space saving
benabik nwc10: I think that comes back to "the plan is to use libuv"
nwc10 the same would apply for a bundled libub
er, libuv
unless and until moarvm can also be installed as a libmoarvm.so which *other* things can link to and embed
I believe that there's no reason to have anything private and bundled done as shared libraries 16:05
benabik patches welcome? 16:07
nwc10 archived *design decisions* and discussion needed
we are where we are due to patches being welcome 16:08
it's not sufficient
and also, I don't have time to do this and everything else
benabik Who does? 16:09
nwc10 also, I'm currently sort-of on holiday and away from the only signifcantly fast machien that I have root on, and can play with adding/removing packages
which for the next 2 weeks makes it hard for me to experiment and produce somethign I'm confident would work
I know someone, but I'm not sure how to lure him
benabik Huh. It looks like APR looks for uuid and then tries to use it, and if it can't just uses its own. Somewhat confused as to how this failed. 16:10
*fails.
nwc10 benabik: *one* of the ways that it failed, when I experiemnted, was that it can see the header, but it doesn't add the link-line to moarvm 16:11
I suspect that moarvm needs to use the APR-generated config script to answer "what other libraries do I need?"
benabik Ahhhh... 16:12
Yeah, that seems likely. I kinda wish ld would load libraries required by libraries.
nwc10 it does
oh, wait
benabik Obviously it don't.
nwc10 in this case, it wasn't told how to
but also, it needs to know paths
assuming it's on-topic enough for the perl 6 hackathon in Kiev, I'll attack it there 16:15
but I don't think that it would wait that long 16:16
and I don't want to *fix* it
I want to teach someone else how to fix it and keep it fixed
and I don't want to keep teaching different people
actually, I don't even want to do that
I want someone else to figure it out, and I answer questions when they are stuck
benabik I suspect this is going to remain slightly broken until we switch to libuv and then people will expend effort to get that right. I think there's not a lot of desire to fix something that's going to be replaced anyway. 16:17
nwc10 right now it's sufficicently broken that bundling APR is counter productive 16:18
the first two machines that I have tried to build moarvm on, it fails 16:19
on one, because uuid.h exists but the -luuid fails
on the second, because the link works, but the use of dynamic libraries means that moarvm is compiled against one set of APR headers, but the system installed (older) APR is found at runtime 16:20
the number of failure modes of the current setup means that there's a reasonably high chance of anyone iterested failing to build it 16:22
which is not good for getting people to play
benabik apr_lib => '3rdparty/apr/.libs/libapr-1.a'
That would be the static library. 16:23
nwc10 yep, but the top level is defaulting to use the shared library
benabik llibs => '-Wl,-Bstatic -lapr-1 [...] 16:25
That's telling LD to use the static version.
nwc10 not on OS X
whatever the build system *said*, I get a runtime failure from the dynamic linker 16:26
benabik Yes, because clang doesn't understand -Bstatic.
nwc10 dyld: Library not loaded: /usr/local/apr/lib/libapr-1.0.dylib Referenced from: /Volumes/Stuff/Perl/MoarVM/./moarvm Reason: Incompatible library version: moarvm requires version 5.0.0 or later, but libapr-1.0.dylib provides version 4.0.0
Trace/BPT trap
benabik I disabled that myself.
nwc10 that I didn't know.
benabik If you're going to install libraries in non-standard paths, you really should alter your environment to include those path in the search. 16:28
And if you can figure out how to tell clang to prefer the static version, that'd be great.
Well, I suppose really "tell OS X's ld" 16:29
nwc10 I didn't tell it to install APR there. Nothing has installed APR there 16:30
that seems to be APR's default
benabik Something has to have installed apr there. OS X comes with it as /usr/lib/libapr 16:31
nwc10 NO, there is no path at that directory
the dylib error as pasted isn't totally truthful
benabik Oh, dear. Stupid install paths.
nwc10 yes
benabik What OS X? 16:32
nwc10 Snow Leopard
benabik Ah. I guess somewhere between .6 and .8 ld learned to look at static over dynamic.
nwc10 sigh, yes, "Get New Utilities" 16:33
benabik No more "ah, that's why it fails for you and not for me"
benabik adds --disable-shared to APR's configured 16:37
If we're not trying to use shared libraries, let's not build it. 16:38
Well, it builds for me. 16:39
benabik submits pull request. 16:43
nwc10: Well, that's one solution to your problems on OS X. 16:44
nwc10 cool, thanks 16:45
jnthn benabik: Hm, I thought I gave you a commit bit...
benabik It shouldn't have broken the build anyway.
jnthn: I've never tried?
jnthn benabik: You have one. :) 16:46
benabik wonders if there's an easy way to tell. 16:47
jnthn benabik: Try pushin' :P
benabik Well, yes.
Well, push refused but that's because my master is out of date. :-D 16:48
dalek arVM: ce69dfd | benabik++ | build/Config/APR.pm:
Don't build APR's dynamic libraries

We're trying to use the static version anyway, so don't waste time building a dynamic library. And hopefully this will help keep some versions of ld *cough*OS X*cough* from trying to use the dynamic version. (OS X is especially bad in that at runtime it searches for where APR says its going to be installed, which is overly confusing.)		 16:53
nwc10 benabik++ # now works on my machine 16:56
that is actually a more elegant solution than I was aware was possible - just disable the dynamic library build
benabik I was searching for an ld option, but then realized "hey, we don't even want that library anyway" 16:58
16:59 not_gerd joined
not_gerd o/ 16:59
personally, I suggest getting rid of -l altogether and just pass in the .a
see gist.github.com/gerdr/5895955
benabik I didn't want to change build environments I don't have. :-D 17:00
It's a good idea though, not_gerd++
FROGGS not_gerd: we had that in the meantime fwiw 17:01
not_gerd FROGGS: why was that changed, if I may ask? 17:02
FROGGS somebody changed it again to make it work on his system 17:03
but I got no answer about what he was thinking about the patch :o)
not_gerd anyway, I'm all for the move to libuv, because that's something that actually builds out-of-the-box on MinGW-64 17:06
nwc10 roll on bootstrapped native compiler 17:07
17:15 colomon joined
not_gerd ~~ 17:18
not_gerd waves goodbye
17:18 not_gerd left
benabik I don't see the build using libapr-1.a directly anywhere in the commit log. 17:57
In particular I don't see any commit that has both a -lapr-1 and libapr-1.a in the diff, which is what I would expect if someone changed from one to the other. (git log --oneline -S-lapr-1 -Slibapr-1.a) 17:59
18:12 tomyan joined 19:09 tomyan joined 19:30 pmichaud joined 22:13 colomon joined 23:02 FROGGS joined 23:31 benabik joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!