Re: make check failure (was: glib under mingw32 debian cross compiler, problem with windres : gmodule-win32res.lo: file not recognized: File format not recognized)

 > Andreas Ames writes:
 >  > The problem with .lo files which are generated by lt-compile-resource
 >  > is that the ltmain.sh script distributed with glib (at least in 2.0.4,
 >  > I didn't try 2.0.6 yet) is too old to support the format of .lo files
 >  > as generated by lt-compile-resource (older ltmain.sh produced and read
 >  > only binary .lo files which were essentially the same as or very
 >  > similar to normal .o files produced by the compiler; newer ones just
 >  > use simple shell scripts).

Tor Lillqvist writes:
 > Hmm, I didn't know (or remember) that. Do you know if these newer
 > versions of libtool accept .lo files that in fact are plain object
 > files? Or do they expect them to always be these short shell scripts?

Turns out that a newer libtool does not like plain object files called
something.lo (and an older libtool does not recognize the newfangled
small scripts). Sigh.

I added an ugly hack to lt-compile-resource: It tries to deduce which
kind of libtool is being used, and acts accordingly. Included below.

--tml

#!/bin/bash

# Script to compile a resource file for a DLL in the same way that
# libtool would, if it knew about .rc files.

# This kinda sucks, but the alternative would be to teach autoconf,
# automake, and libtool about compiling .rc files.  That would be
# doable, but waiting for those changes to propagate to official
# versions of those tools would take some time.

# The command line arguments are:
# $1: the name of the .rc file to compile if it exists
# $2: the name of the resource libtool object file to produce

rcfile=$1
lo=$2
case "$lo" in
*.lo) 
    resfile=.libs/`basename $lo .lo`.o
    ;;
*)
    echo libtool object name should end with .lo
    exit 1
    ;;
esac
d=`dirname $0`

# Create .libs if not there already
[ ! -d .libs ] && mkdir .libs

# Super-ugly hack: libtool can work in two ways on Win32: Either it
# uses .lo files which are the real object files in "this" directory,
# or it creates .o files in the .libs subdirectory, and the .lo file
# is a small text file. We try to deduce which case this is by
# checking if there are any .o files in .libs.

o_files_in_dotlibs=`echo .libs/*.o`
case "$o_files_in_dotlibs" in
    .libs/\*.o)
	use_script=false
	;;
    *)  use_script=true
	;;
esac



# Try to compile resource file
$d/compile-resource $rcfile $resfile && {
    if [ $use_script = true ]; then
	# Handcraft a libtool object
	# libtool checks for a second line matching "Generated by .* libtool"!
	(echo "# $lo"
	echo "# Generated by lt-compile-resource, compatible with libtool"
	echo "pic_object=$resfile"
	echo "non_pic_object=none") >$lo
    else
	mv $resfile $lo
    fi
    # Success
    exit 0
}

# If unsuccessful (no .rc file, or some error in it) return failure

exit 1