Re: 2.2.8 testsuite failures on mac os x 10.6.3 with gcc-4.5

[Ralf Wildenhues]

Hi Peter,

thanks for the report.

* Peter O'Gorman wrote on Sat, Jun 05, 2010 at 10:29:36PM CEST:
> Well, I guess I didn't test with latest gcc before:
> 
> libtool: compile:  gfortran -g -O2 -c main3.f  -fno-common -o .libs/main3.o
> libtool: compile:  gfortran -g -O2 -c main3.f -o main3.o >/dev/null 2>&1
> libtool: compile:  gfortran -g -O2 -c a3.f  -fno-common -o .libs/a3.o
> libtool: compile:  gfortran -g -O2 -c a3.f -o a3.o >/dev/null 2>&1
> libtool: link: ar cru .libs/liba3.a .libs/a3.o
> libtool: link: ranlib .libs/liba3.a
> libtool: link: ( cd ".libs" && rm -f "liba3.la" && ln -s
> "../liba3.la" "liba3.la" )
> ./convenience.at:211: $LIBTOOL --tag=FC --mode=link $FC $FCFLAGS
> $LDFLAGS -o liba12.la liba1.la liba2.la -rpath /notexist
> stderr:
> gfortran: no input files; unwilling to write output files
> stdout:
> libtool: link: gfortran -dynamiclib -Wl,-undefined
> -Wl,dynamic_lookup -o .libs/liba12.0.dylib
> -Wl,-force_load,./.libs/liba1.a -Wl,-force_load,./.libs/liba2.a
> -L/sw/lib    -install_name /notexist/liba12.0.dylib
> -compatibility_version 1 -current_version 1.0 -Wl,-single_module
> ./convenience.at:211: exit code was 1, expected 0
> 29. convenience.at:169: 29. FC convenience archives
> (convenience.at:169): FAILED (convenience.at:211)
> 
> Do we really want to test this with no object files?

I think so, yes.  One issue here was that developers with big build
trees wanted to be able to combine lots of convenience archives from
subdirs into one big library, without necessarily adding more objects.
This is also what the test source documents:

  # Test that convenience archives work.
  # for each TAG, test:
  # - adding one or multiple convenience archives
  # - with or without additional objects on the cmdline

Hmm, for this to work with automake you'd have to override LINK or
libfoo_la_LINK though, too.

I think the workaround we used at the time for compilers like this was
to empty whole_archive_flag_spec, although cheaper workaround could in
principle be used (add dummy object, extract only the first convenience
archive).  It bothers me to see that GCC reintroduces this bug, however.

Cheers,
Ralf