On Nov 4, 2012, at 7:35 PM, Jorge Acereda wrote: > Ok, no need to modify the sources, this is an interpreter, right? ;-) > > > ? (native "@" "dlopen" 'N "lib/ext" 9) > (native "@" "dlopen" 'N "lib/ext" 9) > dyld: loaded: /Users/jacereda/picolisp/lib/ext > dyld: unloaded: /Users/jacereda/picolisp/lib/ext > -> 0 > ? (native "@" "dlerror" 'S) > (native "@" "dlerror" 'S) > -> "dlopen(lib/ext, 9): Symbol not found: _A^J Referenced from: > /Users/jacereda/picolisp/lib/\ > ext^J Expected in: flat namespace^J in /Users/jacereda/picolisp/lib/ext" > ? > > Perhaps the executable shouldn't be stripped?
Bingo, removing the stripping did the trick. All tests pass now. I think it would be better to just mark the symbols that should be exported. Depending on the unstripped executable seems a bit dirty. > > > On Nov 4, 2012, at 6:59 PM, Jorge Acereda wrote: > >> >> On Nov 4, 2012, at 6:43 PM, Alexander Burger wrote: >> >>> On Sun, Nov 04, 2012 at 06:12:36PM +0100, Jorge Acereda wrote: >>>> Works ok on 32 bits: >>>> >>>> bash-3.2$ ./pil lib/test.l $(/bin/pwd) -bye + >>>> OK >>> >>> Interesting. What might be the reason? Is the library format different >>> between those versions? >>> >>> Or do we need some linker command line flag to get the proper format >>> (i.e. holding 'Snx' instead of '_Snx')? >> >> I'm now doubting the underscore is the problem. I wrote the following test >> and it resolves properly the Snx symbol without underscores. >> >> <test.c> >> >> I guess the best is printing dlerror() after the failed dlopen()/dlsym(), >> that might give some hints. >> >> >> >>> >>> Cheers, >>> - Alex >>> -- >>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >> > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
