Re: [Cygwin] [Master] failure when compiling liblangtag

Hi Eike & Peter

Le Tue, 16 Apr 2013 15:44:28 +0200, Eike Rathke <erack@redhat.com> a écrit:

> Hi Mat,
>
> Cc'ing Peter Foley who did the gcc-wrapper.
>
> On Friday, 2013-04-12 23:49:16 +0200, Mat M wrote:
>
> > Command is :
> > C:\cygwin\opt\lo\bin\ccache.exe cl.exe -nologo -EHsc -MD -Gy
> > -Zc:wchar_t- -Ob1 -Oxs -Oy- -DHAVE_CONFIG_H -I. -I..
> > -I../liblangtag/ -I.. -I../liblangtag/ -I.. -D__LANGTAG_COMPILATION  
> > -DBUILDDIR=\"/cygdrive/d/src/libo/workdir/wntmsci13.pro/UnpackedTarball/langtag\"  
> > -DSRCDIR=\"/cygdrive/d/src/libo/workdir/wntmsci13.pro/UnpackedTarball/langtag\"
> > -DREGDATADIR=\"/usr/local/share/liblangtag\"
> > -DLANGTAG_EXT_MODULE_PATH=\"/usr/local/lib/liblangtag\"
> > -ID:/src/libo/workdir/wntmsci13.pro/UnpackedTarball/xml2/include
> > -DG_LOG_DOMAIN=\"LangTag\" -Zi -c -showIncludes lt-database.c
> >
> > So SRCDIR stops at langtag, but lt-database.c is in liblangtag, but
> > we also see make entering liblangtag subdir. The langtag Makefile
> > needs a fix ?
>
> The SRCDIR looks correct, SRCDIR here specifies the top directory where
> the entire source package is located, not it's various subdirectories.
>
> Does the wrapper actually execute the command in that then current
> subdirectory?

I added an output of the CWD and get:
PWD= D:\src\libo\workdir\wntmsci14.pro\UnpackedTarball\langtag\liblangtag
CMD= C:\cygwin\opt\lo\bin\ccache.exe cl.exe -nologo -EHsc -MD -Gy
-Zc:wchar_t- -Ob1 -Oxs -Oy- -DHAVE_CONFIG_H -I. -I.. -I../liblangtag/ -I..
-I../liblangtag/ -I.. -D__LANGTAG_COMPILATION
-DBUILDDIR=\"/cygdrive/d/src/libo/workdir/wntmsci14.pro/UnpackedTarball/langtag\"
-DSRCDIR=\"/cygdrive/d/src/libo/workdir/wntmsci14.pro/UnpackedTarball/langtag\"
-DREGDATADIR=\"/usr/local/share/liblangtag\"
-DLANGTAG_EXT_MODULE_PATH=\"/usr/local/lib/liblangtag\"
-ID:/src/libo/workdir/wntmsci14.pro/UnpackedTarball/xml2/include
-DG_LOG_DOMAIN=\"LangTag\" -Zi -c -showIncludes lt-database.c
cl : Command line error D8003 : missing source filename


When I go to the directory, set the PATH according to the one from
config_host.mk, I get :

mm@FAUCON
/cygdrive/d/src/libo/workdir/wntmsci14.pro/UnpackedTarball/langtag/liblangtag
$ /cygdrive/c/PROGRA~2/MICROS~1.0/VC/bin/cl.exe  -nologo -EHsc -MD -Gy
-Zc:wchar_t- -Ob1 -Oxs -Oy- -DHAVE_CONFIG_H -I. -I.. -I../liblangtag/ -I..
-I../liblangtag/ -I.. -D__LANGTAG_COMPILATION
-DBUILDDIR=\"/cygdrive/d/src/libo/workdir/wntmsci14.pro/UnpackedTarball/langtag\"
-DSRCDIR=\"/cygdrive/d/src/libo/workdir/wntmsci14.pro/UnpackedTarball/langtag\"
-DREGDATADIR=\"/usr/local/share/liblangtag\"
-DLANGTAG_EXT_MODULE_PATH=\"/usr/local/lib/liblangtag\"
-ID:/src/libo/workdir/wntmsci14.pro/UnpackedTarball/xml2/include
-DG_LOG_DOMAIN=\"LangTag\" -Zi -c -showIncludes lt-database.c
lt-database.c
Note: including file:
D:\src\libo\workdir\wntmsci14.pro\UnpackedTarball\langtag\config.h
lt-database.c(17) : fatal error C1083: Cannot open include file:
'string.h': No such file or directory

Which is a different error.
I get the D8003 when I try to run that in another directory, which makes
me think that although getcwd retrieves the current dir, it may not be the
one use as for launching the command. But CreateProcess should use the
same since the parameter is set to NULL [1].
SO really no clue there.

> This error
> > cl : Command line error D8003 : missing source filename
> is not accidentally caused by the -c option being followed by the
> -showIncludes option?

Nope. I tried both to remove any doubt.

> However, what also looks suspicious to me is that the renaming of the
> object file does not occur anywhere on that command line, apparently the
> target should be
>
> >   CC     liblangtag_la-lt-database.lo
> > make[6]: *** [liblangtag_la-lt-database.lo] Error 1
>
> so there should be some -o option followed by the output filename if I'm
> not mistaken.
>
> And, last but not least, why does this fail only for Mat?

My tree is on  29dcdf6b56f8dbc1b7d, and I did a git clean -fxd before make.

> Seeing wntmsci13.pro in the workdir path suggests this is MSVC 2010,
> correct? Maybe that simply works different..
Well, as we tend to support VS 2008, 2010 & 2012 in build setup, we should
have them also supported in gcc-wrapper.
BTW, moved to VS2012 no-express meanwhile

[1]
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx
--
Mat M