Re: [wgcc-dev] Hey ho....

[Duft M. <Mar...@sa...>]

Hey!
=20
Your .wgccrc is corrupt i think. Could you send me the configure output =
from wgcc (config.log), the .wgccrc file thats generated, and the output =
from "env"? That'd tell me more about the problem.
=20
I believe you have to set INTERIX_COMPILERDIR, or set some other =
variables before configuring. Fro details on the check performed to find =
visual studio (at configure time) look at Makefile.py in the package =
toplevel.
=20
Basically thecheck looks for cl.exe, and the sets some paths looking =
from that location onwards. It may be, that your setup is very =
different, than the one that Visual studio uses (the location of the =
runtime headers and libs, and the location of the platformsdk headers =
and libs).
=20
Wgcc fails because of not finding msvcrt.lib, which means that the =
"paths.c =3D ..." section in your .wgccrc is not correct. configure =
simply didn't discover all paths needed.
=20
For sure .wgccrc will contain "paths.c* =3D ..." where ... is at least =
the location where wgcc is installed. (By the way, it's not the best =
idea to install it in /usr/local ;o) since it installs headers in =
prefix/include which are allready there, but completely different.... =
;o//
=20
At the moment i'm fighting to get XP and Server 2003 R2 support up and =
running, Vista will come soon. I allready played around a little there, =
but perl wouldn't work, and i really need it f my builds. (this was Beta =
2)
=20
Cheers, Markus

________________________________

Von: Jerker B=E4ck [mailto:jer...@te...]
Gesendet: Fr 22.09.2006 20:18
An: Duft Markus
Betreff: RE: Hey ho....



OK, managed a gcc build.

Changed the source code like this
#if defined _MSC_VER && defined __INTERIX
    AssemblerTask assembler_task =3D static_cast<AssemblerTask&>(*task);
#else
    AssemblerTask assembler_task =3D =
dynamic_cast<AssemblerTask&>(*task);
#endif

./configure make make install

$ wgcc
$ wgcc -v
warning: unable to match: -v            <blue>warning:</blue>
$

$ cd "F:\dev\Public\Interix\wgcc\wgcc-2.0-rc.2\pxwc-0.6.9"
$ pwd
/dev/fs/F/dev/Public/Interix/wgcc/wgcc-2.0-rc.2/pxwc-0.6.9
$ export CC=3Dwgcc
$ export CXX=3Dwgcc
$ export LD=3Dwgcc
$ ./configure
checking for a BSD-compatible install... /bin/install -c
checking build system type... i586-pc-interix5
checking host system type... i586-pc-interix5
checking target system type... i586-pc-interix5
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... wgcc
checking for C compiler default output file name... configure: error: C
compiler cannot create executables
See `config.log' for more details.

Arrrgh!

Cause: Either cl.exe couldn't be found or linking with wrong libs?
Well, cl.exe is in my path, so is wgcc (/usr/local/bin)

config.log says:
=1B[01;36mwarning: =1B[00mwrapper header set but not available!
=1B[01;35merror  : =1B[00mdebug dumper task failed, using non debug =
link!
=1B[01;36mwarning: =1B[00mwrapper library set but not available!
=1B[01;31mfatal  : =1B[00mlinker task failed!
=1B[01;33mLINK =1B[00m:=1B[01;31m fatal error LNK1181=1B[00m: cannot =
open input file
'msvcrt.lib'

Any comments?

Just a cosmetic note:
Your config.sub and config.guess are outdated
cvs -z3 -d:pserver:ano...@cv...:/sources/config co config

A blunt suggestion:
Why not set up a Vista test machine - RC1 is out and will soon be =
available
to anyone. Rumours says it will have a new more stable posix subsystem =
and
SDK. Anyway, current Vista SUA is almost identical to R2 SUA. The Vista =
WDK
have support for posix apps via build.exe and can be installed on any
workstation. If you just want to try: http://connect.microsoft.com and =
join
the Windows Driver Kit program.

What I mean is that among other things, you can test wgcc against the =
coming
Interix 6 and watch for changes in the cc script.

Some reactions on your reactions on my reactions:
> with cc it would be a windows build
> ... ring in lots of hacks to make things work
Frankly, as far as I can see  - no
Your current code compiles elegantly with cc =3D> posix app
The problem is the libtool - I think.
Anyway, Interix is built with build.exe =3D> nmake.exe =3D> cl.exe and =
some
utils with cc =3D> cl.exe. I couldn't find any official interix =
executable
built with gcc (except itself). It's easy to find that out with =
depends.exe.


Regards Jerker


________________________________

From: Duft Markus [mailto:Mar...@sa...]
Sent: Friday, September 22, 2006 5:42 PM
To: Jerker B=E4ck; int...@li...
Subject: AW: Hey ho....


Hey again!

The thing is, that wgcc should be the _lowest_ tool used in an interix
environment. means there should be no other requirements, except a =
bootstrap
compiler. using gcc is just as fina as using anything else, so i'm using =
gcc
to build wgcc. anything else would require mie to hack something for the
windows build to include interix stuff which i don't want it to be. the
windows build should be plain windows, and should _never_ know anything
about interix.
For that reason there is an interix build (using gcc). with cc it would =
be a
windows build. Since wgcc was written to _replace_ cc (for me) i think =
it's
senseless to build wgcc with cc. this would just bring in lots of hacks =
to
make things work that would work anyway, and break things which _must_ =
work
(like RTTI ;o))

wgcc supports using third party C++ runtimes (stdcxx was used here, but
anything else may be subtituted in instead, see .wgccrc (stdcxx.* =
options)).

I repeat wgcc is the build tool, not a package built using some build =
tool,
except the "native" compiler (where the interix native compiler is =
gcc/g++,
and on win32 cl.exe is the native compiler). Anything else would be a
cross-compilate, and producing those is definitly the task of wgcc.

I'll look into adding a INSTALL file, or adding instructions to the =
docs.

if you still wan't to look into this: to disable libtool you need to
bootstrap the package. This is done using confix =
(confix.sourceforge.net)
which needs python 2.4. you can use a windows python. when confix is
installed use:

confix.py --boo

inside the wgcc source tree. if you want to enable libtool use:

confix.py --boo --use-libtool

wish you a nice weekend too ;o)
Cheers, Markus

________________________________

Von: Jerker B=E4ck [mailto:jer...@te...]
Gesendet: Fr 22.09.2006 17:03
An: Duft Markus
Betreff: RE: Hey ho....



> Sorry, i forgot to tell you to build wgcc with gcc/g++
OK, I go for a temporarily gcc build

Please write a detailed INSTALL file with instructions how to build in =
the
package.

I suspected that this is necessary in SFU since a MS C++ library is =
missing.
In SUA on the other hand we have a variant of the Dinkum library shipped
with VS 2005. In R2 SUA this is more or less a kind of quick and dirty =
port
but it will hopefully be improved in Vista SUA.

Of course I would not satisfy until I have a working build with the MS
tools. Can you examine my config.log to see where it goes wrong? Is =
there
any way to disable the libtool to let cc find it own libraries?

Note: A posix build in Visual Studio should work as good as any other
builds. Is there any special gcc tweaks (or GNU C++ library tweaks) =
used?

> Using the cc script to build is absolutely _not_ supported,
> since it uses different libraries, and different options...

Maybe a little early to argue about this until I have a working test
application, but here I absolutely disagree. Support for cc is really a =
MUST
HAVE. I also suspect a lot of people have tweaked their own C++ =
libraries
for SFU (based on MS Dinkum, stdcxx or STLport). So in my opinion, in =
any
case the C++ library used should be a matter of choice of the user.

Have a nice weekend
Jerker