Re: PATCH fixups for proper setting of archive_cmds_need_lc

[Charles Wilson]

Albert Chin wrote:

> I disagree with treating the C tag specially. No tag should be treated
> any different than another.

If you mean this in general (and not just as it relates to this -lc 
issue), then there's this comment from when I originally folded stuff 
into the AC_LIBTOOL_POSTDEP_PREDEP function

        (AC_LIBTOOL_POSTDEP_PREDEP): new function.
        moved the "find hidden library dependencies" code here
        from AC_LIBTOOL_LANG_CXX_CONFIG.  Attempted to make it
        multi-tag compatible, but currently only CXX calls it.

> Eventually, even the "C" tag should call AC_LIBTOOL_POSTDEP_PREDEP, so 
> that the behavior in all tags is the same (e.g. if NOT 
> allow_libtool_libs_with_static_runtimes, then the C tag should check 
> libgcc for "dynamicness" -- existing behavior is to allow static 
> libgcc.a when creating C shared libs, but disallow in C++.  ???)  But, 
> again, one thing at a time.
>
> Further, somebody "in charge" might decide that C should behave more 
> like C++ -- in that it should define an
>     output_verbose_link_cmd
> call
>     AC_LIBTOOL_POSTDEP_PREDEP([tagname])
> (which would add the "hidden" libs to $postdeps, $predeps, etc), and 
> change all link commands (for tag=C) to use
>    -nostdlibs
> But that's a radical change and not one I'm comfortable making on my own 
> -- and AC_LIBTOOL_POSTDEP_PREDEP really should get a shakedown on other 
> platforms, restricted to tag=C++, first.

I think AC_LIBTOOL_POSTDEP_PREDEP has gotten its shakedown, but there 
are other changes needed in the "C" codepath before C can be treated 
like C++/other tags.

OTOH, that may be too radical a change to contemplate this "close" to a 
release.  If we are, in fact, close. <g>

--Chuck