gnu-smalltalk 3.4.2 build fails (+ issue tracker web bug)

> On 04/29/2011 03:50 PM, Roland Plüss wrote:
>> Tried to build 3.4.2 on Kubuntu 64bit without success. Wanted to report
>> this using the issue tracker but the account creation there is bugged
>> (form does not show any captcha fields but complains about missing
>> captcha) so I try it this way.
>>
>> The build seems to fail at the link stage (gst) but I can't make heads
>> or tail out of the error message:
>>
>>  >>>
>> (...)
>> make[2]: Betrete Verzeichnis '/home/roland/progs/smalltalk-3.2.4'
>> gcc -DHAVE_CONFIG_H -I. -I./libgst -I./lib-src
>> -DCMD_XZIP="\"/usr/bin/zip\"" -DCMD_INSTALL="\"/usr/bin/install -c\""
>> -DCMD_LN_S="\"ln -s\""
>> -DDEFAULT_EXECUTABLE=\""/home/roland/progs/testing/opt/gnu-smalltalk/bin/gst"\"
>>
>> -g -O2 -Wall -Wdeclaration-after-statement -Wno-format -Wpointer-arith
>> -Wno-pointer-sign -Wwrite-strings -Wno-strict-aliasing -Wno-switch
>> -fno-gcse -fstrict-aliasing -MT main.o -MD -MP -MF .deps/main.Tpo -c -o
>> main.o main.c
>> mv -f .deps/main.Tpo .deps/main.Po
>> /bin/bash ./libtool --tag=CC --mode=link gcc -g -O2 -Wall
>> -Wdeclaration-after-statement -Wno-format -Wpointer-arith
>> -Wno-pointer-sign -Wwrite-strings -Wno-strict-aliasing -Wno-switch
>> -fno-gcse -fstrict-aliasing -export-dynamic -Wl,-rpath,"\$ORIGIN/../lib"
>> -L/home/roland/progs/testing/lib -o gst main.o libgst/libgst.la
>> lib-src/library.la -lrt -lm
>> libtool: link: cannot find name of link library for
>> `/home/roland/progs/smalltalk-3.2.4/libc.la'
>> make[2]: *** [gst] Fehler 1
>> make[2]: Verlasse Verzeichnis '/home/roland/progs/smalltalk-3.2.4'
>> make[1]: *** [all-recursive] Fehler 1
>> make[1]: Verlasse Verzeichnis '/home/roland/progs/smalltalk-3.2.4'
>> make: *** [all] Fehler 2
>> <<<
>>
>> Error line is
>> libtool: link: cannot find name of link library for
>> `/home/roland/progs/smalltalk-3.2.4/libc.la'
>>
>> which doesn't make any sense to me. Any help appreciated.
>
> Try removing the file, then reinvoke the last line manually.  If that
> works, please send the contents of the libc.la file.
>
> Paolo

> On 04/30/2011 05:16 PM, Roland Plüss wrote:
>>>> >>  Removed the libc.la and called "make" again. This did the
>>>> trick. Maybe
>>>> >>  the Makefile should be improved to remove this file before
>>>> compiling so
>>>> >>  it does not cause any troubles with libtool.
>>> >  The file_is_  needed, I just wanted to make sure it was at fault.:)
>> For what is it needed? It's in the way. I'm having la-remove-hooks in my
>> SCons with every lib/exe as libtool frenetically keeps producing these
>> useless buggers causing troubles down the lane.
>
> It is needed to use libc functions from Smalltalk functions.  It is
> not a "normal" .la file, as it is not produced by libtool but rather
> used by libltdl.

> On 05/03/2011 12:52 AM, Roland Plüss wrote:
>> Should this not be the job of the dynamic linker to resolve libraries
>> instead of the app messing with it?
>
> No, the dynamic does assume that the app know the soname (it is a bad
> idea to pass things like "libfoo.so" without the full soname to the
> dynamic linker, because you don't know what ABI you'll get; and anyway
> it doesn't work for glibc).
>
> So, it is the job of the VM to insulate this from Smalltalk programs.
> Then they can do
>
>     DLD addLibrary: 'libc'
>
> rather than
>
>     DLD addLibrary: 'libc.so.6'
>
> or
>
>     DLD addLibrary: 'libSystem.dylib'
>
> and so on.