|
06:15
evalable6 left
|
|||
| ab5tract | I'm experiencing some bizarre behavior when trying to use a zig compiled moar on Linux/x64: gist.github.com/ab5tract/89fd81b1d...c1b70bd9f6 | 11:09 | |
| lizmat | meh | 11:30 | |
| ab5tract | updated the gist with ldd and objdump details. ldd loses track of libmoar.so but objdump reports the same rpath expectations | 15:41 | |
| timo | you can set LD_DEBUG to something like "all" or "files" or "libs" and see what looking for the .so file looks like | 15:44 | |
| ab5tract | updated with the failure mode with LD_DEBUG="all" in the gist | 15:56 | |
| I figured you wouldn't want to see the success mode with its 335k lines | |||
| oops, LD_DEBUG simply advances its own line counter | 15:58 | ||
| updating with the success case too | |||
| timo | are we sure that Configure.pl did nothing to these files? that's weird | 15:59 | |
| ab5tract | it's so bizarre. I can't even find the location where it calls the moar executable | 16:00 | |
| oh, I'm probably ignoring these system_or_die calls | |||
| scratch that, I still don't see it | 16:09 | ||
| so it's not just Configure.pl, it dies when make is run directly too: gist.githubusercontent.com/ab5trac...tfile5.txt | 16:11 | ||
| timo | when it outputs "./libmoar.so (0x00007f5a68400000)" does that refer to an actual libmoar.so in the CWD? should it not be outputting a second path in ldd when it finds it according to the runpath? | 16:12 | |
| ab5tract | I assumed it referred to the libmoar.so at ../lib/./libmoar.so | 16:21 | |
| but you have made me realize that I haven' | |||
| I haven't gathered any example of what these look like for me under a gcc build | |||
|
17:09
librasteve_ joined
|
|||
| ab5tract | note also that copying the libmoar.so file into the same directory as moar | 17:16 | |
| doesn't fix anything | |||
|
23:43
woodi_ left,
woodi joined
|
|||