Re: smalltalk-3.2: installation failure on glibc system

[Gary V. Vaughan]

Hi Bruno,

On 3 May 2010, at 01:07, Bruno Haible wrote:
> I'm trying to install GNU smalltalk 3.2 on a bi-arch (i386, x86_64) system
> in 32-bit mode [[...]]
> 
> ../snprintfv/snprintfv/.libs/libsnprintfvc.a |  | 
> /arch/x86_64-linux/gnu/bin/sed 's/.* //' | sort | uniq > .libs/libgst.exp
> 
> [[...]]
> # Take the output of nm and produce a listing of raw symbols and C names.
> global_symbol_pipe=""
> 
> # Transform the output of nm in a proper C declaration.
> global_symbol_to_cdecl=""
> 
> [[...]]
> 
> # The commands to list exported symbols.
> export_symbols_cmds="\$NM \$libobjs \$convenience | \$global_symbol_pipe | 
> \$SED 's/.* //' | sort | uniq > \$export_symbols"

Thanks for the report.

> There are two problems here:
> 
> 1) NM has been set to "link -dump -symbols". This is wrong. This setting 
> should
>   only be valid when the --host platform is win32 and the build platform is
>   not cygwin. I have an /usr/bin/nm program in $PATH, that works fine for
>   both 32-bit and 64-bit object files on my platform.
> 2) global_symbol_pipe has been set to empty.


_LT_CMD_GLOBAL_SYMBOLS is the macro responsible for setting global_symbol_pipe, 
and by inspection of that code, it seems that the only way for it to be empty 
is if the internal test to ensure that it works fails.  Probably this is a 
symptom of the other problem.

LT_PATH_NM is the macro responsible for setting NM, although it doesn't run if 
NM has already been set.  Again, by inspection NM is only set to "link -dump 
-symbols" if the test for a working $NM fails... either because the flag 
combinations tried by the macro don't produce the expected output, or if NM 
itself is not set properly.  You can narrow this down by rerunning configure 
with NM set in the environment to the full path of the nm binary you would have 
expected libtool to chose.  If it still fails then the macro is not able to 
find the right flags to make that NM produce output that is useful, otherwise 
if it starts working then the macro is not finding the NM you set manually in 
your PATH (or a few other well known locations).

> When I google for
>  "libtool eval" "link -dump -symbols"
> I find dozens of reports of libtool errors that were due to the same
> problem: NM being set to "link -dump -symbols" on platforms unrelated to win32
> (Linux, MacOS, NetBSD etc.).

That seems like a good reason to fail early.  If LT_PATH_NM is unable to find a 
working nm binary when {,cross-}compiling for an MS target, then we should be 
causing configure to bail out with an error rather than wait for link-time 
errors on a badly chosen NM setting.  Although, I'm not sure yet whether 
NM="garbage" is a showstopper for libtool... probably libtool is still useful 
for linking libraries with no -export-symbols* flags even in this case. 
Comments?

Please let us know whether manual NM export works for you (and what value you 
used, and whether the nm binary you chose was along your command search PATH), 
so we can figure out where the error is.

Cheers,
-- 
Gary V. Vaughan (address@hidden)