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? 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
