gfortran link failure in current llvm svn

The curent llvm svn (r54623) is unable to link the gfortran
compiler in llvm-gcc-4.2 svn. I am getting the error...

c++ -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -mdynamic-no-pic -DHAVE_CONFIG_H -o f951 \
    fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o fortran/data.o fortran/decl.o fortran/dump-parse-tree.o fortran/error.o fortran/expr.o fortran/interface.o fortran/intrinsic.o fortran/io.o fortran/iresolve.o fortran/match.o fortran/matchexp.o fortran/misc.o fortran/module.o fortran/openmp.o fortran/options.o fortran/parse.o fortran/primary.o fortran/resolve.o fortran/scanner.o fortran/simplify.o fortran/st.o fortran/symbol.o fortran/convert.o fortran/dependency.o fortran/f95-lang.o fortran/trans.o fortran/trans-array.o fortran/trans-common.o fortran/trans-const.o fortran/trans-decl.o fortran/trans-expr.o fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-openmp.o fortran/trans-stmt.o fortran/trans-types.o llvm-main.o libbackend.a ../libcpp/libcpp.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMBitReader.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMipo.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMBitWriter.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/LLVMX86.o /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMSelectionDAG.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMCodeGen.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMScalarOpts.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMTransformUtils.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMipa.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMAnalysis.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMTarget.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMCore.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMSupport.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMSystem.a attribs.o stub-objc.o stub-c.o -L/sw/lib -lmpfr -lgmp ../libcpp/libcpp.a ./../intl/libintl.a /usr/lib/libiconv.dylib ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib -lpthread -lm
Undefined symbols:
  "_create_init_utf16_var", referenced from:
      _darwin_build_constant_cfstring in libbackend.a(darwin.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[3]: *** [f951] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2

Why is c++ being used instead of /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_gcc42_objdir/./prev-gcc/xgcc?
              Jack

Hi Jack,

   The curent llvm svn (r54623) is unable to link the gfortran
compiler in llvm-gcc-4.2 svn. I am getting the error...

...

Undefined symbols:
  "_create_init_utf16_var", referenced from:
      _darwin_build_constant_cfstring in libbackend.a(darwin.o)

this is probably due to recent Apple changes. Fortran builds on
linux.

Why is c++ being used instead of /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_gcc42_objdir/./prev-gcc/xgcc?

I think this is because some people may not have C++ in the list
of languages to build. There's even a PR about this:
http://llvm.org/bugs/show_bug.cgi?id=1150

Ciao,

Duncan.

Duncan,
   I don't be that can be the cause because I have...

--enable-languages=c,c++,fortran

in my configure options for llvm-gcc-4.2.
                   Jack

   I don't be that can be the cause because I have...

--enable-languages=c,c++,fortran

in my configure options for llvm-gcc-4.2.

I meant that it uses the system c++ not because you didn't
configure with c++ in --enable-languages, but because someone
might not configure with c++. I suppose the build system
could be modified to use the just built g++ if it exists,
and the system c++ compiler otherwise, but currently it
doesn't do that.

Ciao,

Duncan.

Duncan,
   I am confused. Shouldn't the gcc 4.2 front-end build behave
just like the FSF gcc build. The first stage builds the compilers
and the second stage rebuilds them using those from the first
stage?
                     Jack

Hi,

   I am confused. Shouldn't the gcc 4.2 front-end build behave
just like the FSF gcc build. The first stage builds the compilers
and the second stage rebuilds them using those from the first
stage?

the FSF gcc requires you to build the C compiler (I think - will check).
Thus a newly built C compiler is always available to build later stages.
We can't reasonably require everyone to build the C++ compiler (I
often don't - it speeds up the build considerably). So we would
need some new logic to handle this situation. It can doubtless
be done, but hasn't been done - mucking with the gcc build system
can be quite an adventure!

Ciao,

Duncan.

Duncan,
    Actually, shouldn't this be just an error in the Makefile.in or
Makefile.am? Why should a link line like...

c++ -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -mdynamic-no-pic -DHAVE_CONFIG_H -o f951 \
    fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o fortran/data.o fortran/decl.o fortran/dump-parse-tree.o fortran/error.o fortran/expr.o fortran/interface.o fortran/intrinsic.o fortran/io.o fortran/iresolve.o fortran/match.o fortran/matchexp.o fortran/misc.o fortran/module.o fortran/openmp.o fortran/options.o fortran/parse.o fortran/primary.o fortran/resolve.o fortran/scanner.o fortran/simplify.o fortran/st.o fortran/symbol.o fortran/convert.o fortran/dependency.o fortran/f95-lang.o fortran/trans.o fortran/trans-array.o fortran/trans-common.o fortran/trans-const.o fortran/trans-decl.o fortran/trans-expr.o fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-openmp.o fortran/trans-stmt.o fortran/trans-types.o llvm-main.o libbackend.a ../libcpp/libcpp.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMBitReader.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMipo.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMBitWriter.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/LLVMX86.o /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMSelectionDAG.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMCodeGen.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMScalarOpts.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMTransformUtils.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMipa.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMAnalysis.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMTarget.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMCore.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMSupport.a /sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMSystem.a attribs.o stub-objc.o stub-c.o -L/sw/lib -lmpfr -lgmp ../libcpp/libcpp.a ./../intl/libintl.a /usr/lib/libiconv.dylib ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib -lpthread -lm

..even require c++ instead of xgcc?
                             Jack

Hi Jack,

    Actually, shouldn't this be just an error in the Makefile.in or
Makefile.am? Why should a link line like...

...

..even require c++ instead of xgcc?

because xgcc may not support c++. I'm not saying that it can't
be done, just that it has not been done. Like anything, someone
has to sit down and do it, and nobody has done so yet.

Ciao,

Duncan.

Duncan,
     So you agree that nothing on that offending link line is
really requiring g++? I'll see if I can find the lines in
Makefile.in and Makefile.am that are producing that link line
and propose a patch. I don't see why the linkage of the gfortran
compiler itself should have anything to do with c++ code. Not even
FSF gcc trunk has switched over to building with c++ yet. I assume
that's also not the case with the llvm gcc 4.2 front end.
               Jack

Generally if there are any C++ components on your link line (such as LLVM), you need to
link with c++; otherwise it won't look for libstdc++ and whatever else the local c++ installation needs.

Hi Jack,

     So you agree that nothing on that offending link line is
really requiring g++?

it does require g++ in order to get the standard C++ libraries.

...I don't see why the linkage of the gfortran
compiler itself should have anything to do with c++ code.

Because the llvm parts of gcc are written in C++. Not to
mention llvm itself!

Not even
FSF gcc trunk has switched over to building with c++ yet. I assume
that's also not the case with the llvm gcc 4.2 front end.

Parts of llvm-gcc are written in C++.

Ciao,

Duncan.

This function is defined in config/darwin-c.c. Are you building & linking that in?

-bw

I just looked at what's going on here, and I threw up a little in my mouth.

It's just horrendous. For some reason, they placed a whole bunch of ObjC-building code into darwin.c, then had it call this function in darwin-c.c. If I try to put that function into darwin.c, all hell breaks loose. So even though the Fortran stuff wouldn't call the Obj-C stuff in darwin.c, it appears like it still needs the darwin-c.c file linked in with it.

-bw

IMHO, this is one of my biggest concerns about Apple eventually
switching over to llvm-gcc. The absence of the rigorous patch
review process required in FSF gcc will tend to allow these sort
of issues to slip by.
               Jack

It's not an llvm-gcc vs gcc thing. We sync our code base up with Apple's gcc branch.

-bw

It's just horrendous.

The standard answer, we welcome your contribution.

it appears like it still needs the darwin-c.c file linked in with it.

No. That way lies insanity. You want to create stub routines in the ada/java/fortran front ends, or move the C specific bits into darwin-c.c and ensure that the language independent parts don't directly call anything from a C part.

> it appears like it still needs the darwin-c.c file linked in with it.

No. That way lies insanity. You want to create stub routines in the
ada/java/fortran front ends, or move the C specific bits into darwin-
c.c and ensure that the language independent parts don't directly call
anything from a C part.

There are already stub-c.c and stub-objc.c, which are used by the various
non-C front-ends to work around the existing worms in the Apple.

Ciao,

Duncan.

You add these routines in stub-objc.c for other FEs.

This is wrong in this case.

Ah, stub-c.c is a llvm invention I wasn't up on... I think Devang meant that file. I think that should work.