Building collect2 for C?

[E. Weddington]

On 16 Mar 2004 at 9:59, Ian Lance Taylor wrote:

> "E. Weddington" <eric@ecentral.com> writes:
> 
> > In my mind, this implies that collect2 is only necessary for compiling C++,
> > and not necessary for C. Is this correct?
> 
> Yes.

On 16 Mar 2004 at 9:07, David Edelsohn wrote:
 
>  GCC C code can include constructors, destructors, and exception
> handling frames.

Which is it then?

 
> > And if that is correct, is there any real reason why collect2 is attempting to
> > be built when configuring with?:
> > 
> > ../gcc-$version/configure --prefix=$mixedinstalldir --host=mingw32 \
> >     --build=mingw32 --target=m68k-elf \
> >     --enable-languages=c --without-headers --with-newlib --disable-shared
> >     --disable-threads \ --with-local-prefix=$mixedinstalldir/m68k-elf
> > 
> > (i.e., configuring with no C++, just C.)
> 
> Building collect2 is independent of --enable-languages.  I suppose the
> Makefile machinery could be changed to not build collect2 when
> --enable-languages=c is used.  That would probably lead to some other
> set of problems, though.

Granted. However I just received a post from Rolf Ebert pointing out PR 14548:
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14548>
And Rolf said to me about this: "... as the Makefile tries to build collect2 on 
MinGW for target gnatlib_and_tools.  The proposed solution was to move the 
target collect2 into another part of the Makefile machinery."

 
> > This is related to PR #14316:
> > <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14316>
> > because the build fails on collect2.
> > 
> > So, if collect2 really has nothing to do with C, should the fact that it's
> > attempting to be built for C be considered a bug?
> 
> I don't think that is the real bug here.

No, not really. The real bug that I'm trying to work around is 14316 above. 
14316 contains a link to a discussion from over a year ago between Zack and DJ 
about Zack's proposed patch. I don't fully understand the reasons DJ gave for 
blocking that patch: I can't tell from that discussion whether it's an 
objection based on libiberty itself, or an objection based on that the proposed 
patch doesn't work for DJGPP. 

If it's an objection based on that the proposed patch doesn't work for DJGPP, 
then I would ask that the objection be dropped as the PR has nothing to do 
DJGPP, it has to do with MinGW. I would rather that a fix for MinGW get in and 
open a new PR based on DJGPP and have it fixed at a later point. IMHO, It 
doesn't seem right to hold up a fix on one platform, based on a problem on 
another platform.

Eric Weddington