On 25/09/2011 16:42, jojelino wrote:
> lstdc++ is included in postdeps in libtool for some reason.
>
> postdeps="-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname
> -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd
> -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt"
>
> this postdeps was introduced by
> output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 |
> $GREP -v "^Configured with:" | $GREP "\-L"'
>
> but in config.status,
> postdeps=''
> postdeps_CXX='-lstdc++ -lmingwthrd -lmingw32 -lgcc_s -lgcc -lmoldname
> -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingwthrd
> -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt'
> so it seems good.
> therefore, this problem began from *executing libtool commands*.
> the variable 'postdeps' is not tagged with "_CXX". resulting in
> wrong-generated libtool
I think this is just libtool working normally; $postdeps is the current
dependencies for this particular invocation, and internally it's doing
something like "postdeps=${postdeps_${tag}}" so it's setting
postdeps=$postdeps_CXX in response to getting --tag=CXX on the command-line,
isn't it? The underlying cause is more likely to be in the way that the
Makefile.am is setting the libtool control variables, which is probably an
issue for upstream.
(And of course this doesn't show up on Linux, where the linker doesn't
complain about a dynamic library not being found because it can just leave
undefined reference in the final executable to be resolved by ld.so at
runtime. But as soon as you try it on a PE rather than ELF platform...)
cheers,
DaveK
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
