Ok, what about this?

Attachment: macstrip.patch
Description: Binary data


According to the strip man page:

       -x     Remove all local symbols (saving only global symbols).



On Nov 4, 2012, at 7:39 PM, Jorge Acereda wrote:

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

Reply via email to