interix-wgcc-developer — Developer List

Re: [wgcc-dev] wgcc does not build

[Martin K. <mk...@gm...>]

Hi Markus,

> I wrote wgcc with the main intention to get native windows binaries that
> are plain win32 and have nothing to do anymore with any unix subsystem
> or something, since this gave lots of problems, especially with
> debugging. For example try to build wgcc debuggable with gcc and debug
> with gdb -> it's really impossible ;o)

yes, that's a problem. :-(

> Debugging with visual studio is really cool only when building really
> native (linking with link.exe) maybe the best woulb be building with gcc
> and linking with link.exe.

agreed here, too.

To continue my last mail for motivations for creating POSIX-CUI 
exes with MS tools, I have these:

- One could have link.exe via wgcc as drop-in replacement for ld, 
which is buggy in some situations. (Of course then there is only 
static linking...)

- gcc/g++ 3.3 is rather old now, so cl.exe could be used, e.g. instead 
of g++ to have better C++ support.


> If you look at the source code of wgcc it would be not a big problem
> implementing alternative compiler/linker tasks, since everything is
> really modular.

sounds good.

> At the moment i don't have enough time to work on this, but i will take
> a look at it in the near future, since it sounds promising and desirable
> to make wgcc able of using the interix tools too. This would make wgcc
> the most powerfull build tool for interix around (and most configurable
> one)...
>
> I played around with wgcc and ld, and it seems to work for a small hello
> world.... Really cool would have been beeing able of using msvcrt libc
> when linking with ld, but there seem to be some restriction, since i
> can't seem to be able to execute the resulting binary (but link goes ok
> without even a warning)...
>
> As far as i now see, using either ld or gcc forces the use of the
> interix libc & co. This is for our (company) current situation not
> really desireable as i allready said, but since wgcc is an open source
> project i'm willing to spend some time in implementing this anyway -
> when i got some time ;o)

Thank you. Can you approximately say, when this might happen?

> As far as building bash & co. With cl.exe is concerned: be aware of
> compiler capability differences... For example gcc uses
> __atribute__(...) and MS uses __declspec(...) which each other don't
> understand. So the sources will most likely not build. One more thing
> is, that you would have to first port libtermcap or libncurses or so to
> cl.exe, which as far as i know would be _really much_ work...

>From gcc-4.1 docs:
You can use __declspec(dllexport) as a synonym for __attribute__ 
((dllexport)) for compatibility with other compilers.

But: for .so files, you don't need any of __attribute__ or __declspec. 
.so libs are not DLLs! I currently don't know much technical detail, 
but they are different. That's why only ld can link (to) them. The 
general idea is of course the same, though.

See here for some details:
http://www.interopsystems.com/tools/tm.aspx?m=7904

>> Many questions ;o) maybe you want to try (after wgcc works ;o)) to 
>> only compile with wgcc, and manually link with ld and gather some 
>> experience in this direction.... I will try too!
>
> Ok, will try with wgcc, too.

This doesn't work, because wgcc compiles with Win32 libc headers, so 
gcc/ld complains when linking:

$ wgcc -g -c -o hello.o hello.c
$ gcc hello.o
hello.o(.text+0xc): undefined reference to `__imp__printf'
collect2: ld returned 1 exit status

Martin

Re: [wgcc-dev] wgcc does not build

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

Hi!

I wrote wgcc with the main intention to get native windows binaries that
are plain win32 and have nothing to do anymore with any unix subsystem
or something, since this gave lots of problems, especially with
debugging. For example try to build wgcc debuggable with gcc and debug
with gdb -> it's really impossible ;o)

Debugging with visual studio is really cool only when building really
native (linking with link.exe) maybe the best woulb be building with gcc
and linking with link.exe.

If you look at the source code of wgcc it would be not a big problem
implementing alternative compiler/linker tasks, since everything is
really modular.

At the moment i don't have enough time to work on this, but i will take
a look at it in the near future, since it sounds promising and desirable
to make wgcc able of using the interix tools too. This would make wgcc
the most powerfull build tool for interix around (and most configurable
one)...

I played around with wgcc and ld, and it seems to work for a small hello
world.... Really cool would have been beeing able of using msvcrt libc
when linking with ld, but there seem to be some restriction, since i
can't seem to be able to execute the resulting binary (but link goes ok
without even a warning)...

As far as i now see, using either ld or gcc forces the use of the
interix libc & co. This is for our (company) current situation not
really desireable as i allready said, but since wgcc is an open source
project i'm willing to spend some time in implementing this anyway -
when i got some time ;o)

As far as building bash & co. With cl.exe is concerned: be aware of
compiler capability differences... For example gcc uses
__atribute__(...) and MS uses __declspec(...) which each other don't
understand. So the sources will most likely not build. One more thing
is, that you would have to first port libtermcap or libncurses or so to
cl.exe, which as far as i know would be _really much_ work...

Have Fun ;o) Markus

-----Original Message-----
From: Martin Koeppe [mailto:mk...@gm...]=20
Sent: Tuesday, October 10, 2006 3:02 PM
To: Duft Markus
Cc: int...@li...
Subject: RE: wgcc does not build



Hi Markus,

On Tue, 10 Oct 2006, Duft Markus wrote:

> First: I'm really really glad to get some feedback at last ;o) please=20
> direct your mails to the int...@li...=20
> so the mails get archived... I'll in any case CC you if you don't want

> to subscribe.

ok, and please cc me.

> The last lines are less interesting than the first errors ;o) could=20
> you send me a complete output? How are you building, have you read the

> INSTALL file? You could also attach the output from env. Which version

> of Interix are you using, and which version of Windows.

ok, of course. I only took the last lines of the terminal. Now I tried
2.0.3 too:

$ uname -X
System =3D Interix
Node =3D interix3
Release =3D 3.5
Version =3D SP-8.0.1969.45
Machine =3D x86
Processor =3D Intel_x86_Family15_Model2_Stepping8
HostSystem =3D Windows
HostRelease =3D SP4
HostVersion =3D 5.0

build was successful this time, I had some bad libs in CPPFLAGS /
LDFLAGS / LIBS, which I cleared now before building. It was my fault.

> I did never try to link with wgcc output with ld, why would you like=20
> to do this? If it works, this could really be worth an extension. Does

> the resulting binary depend on the microsoft runtime, or the interix=20
> runtime. Can i use the windows api, and more important, can i use the=20
> microsoft debugger (visual studio).

This works, at least for a simple hello program. Even in both
directions, i.e. within interix:

interix$ cc -c hello.c
interix$ gcc hello.o

The other direction would be:

interix$ gcc -c hello.c
win32> link.exe (with several options I currently don't have
available, but I can search them later)

But both gave valid interix (i.e. POSIX CUI) executables.

The intension here is to explicitely not use the VC runtime, but the=20
interix runtime and libc and all other libs available there. Therefore=20
the Windows API is not and for me should not be available. I don't=20
know about debugging support, but I read that it would be possible to=20
debug plain POSIX apps with VS.

Debugging is not that important for me, as I currently want to build=20
well known apps as bash, gnu make, gnu find etc. with cl.exe, just to=20
verify that it works, and to be able to use cl.exe's warnings in=20
comparison to gcc's warnings, just to possibly get the code more=20
clean. I think it's better when it even works with several compilers.

Linking with gcc/ld is necessary for .so libs.

> Many questions ;o) maybe you want to try (after wgcc works ;o)) to
only
> compile with wgcc, and manually link with ld and gather some
experience
> in this direction.... I will try too!

Ok, will try with wgcc, too.

Martin

Re: [wgcc-dev] wgcc does not build

[Martin K. <mk...@gm...>]

Hi Markus,

On Tue, 10 Oct 2006, Duft Markus wrote:

> First: I'm really really glad to get some feedback at last ;o) please
> direct your mails to the int...@li... so
> the mails get archived... I'll in any case CC you if you don't want to
> subscribe.

ok, and please cc me.

> The last lines are less interesting than the first errors ;o) could you
> send me a complete output? How are you building, have you read the
> INSTALL file? You could also attach the output from env. Which version
> of Interix are you using, and which version of Windows.

ok, of course. I only took the last lines of the terminal. Now I tried 
2.0.3 too:

$ uname -X
System = Interix
Node = interix3
Release = 3.5
Version = SP-8.0.1969.45
Machine = x86
Processor = Intel_x86_Family15_Model2_Stepping8
HostSystem = Windows
HostRelease = SP4
HostVersion = 5.0

build was successful this time, I had some bad libs in 
CPPFLAGS / LDFLAGS / LIBS, which I cleared now before building. It was 
my fault.

> I did never try to link with wgcc output with ld, why would you like to
> do this? If it works, this could really be worth an extension. Does the
> resulting binary depend on the microsoft runtime, or the interix
> runtime. Can i use the windows api, and more important, can i use the
> microsoft debugger (visual studio).

This works, at least for a simple hello program. Even in both 
directions, i.e. within interix:

interix$ cc -c hello.c
interix$ gcc hello.o

The other direction would be:

interix$ gcc -c hello.c
win32> link.exe (with several options I currently don't have 
available, but I can search them later)

But both gave valid interix (i.e. POSIX CUI) executables.

The intension here is to explicitely not use the VC runtime, but the 
interix runtime and libc and all other libs available there. Therefore 
the Windows API is not and for me should not be available. I don't 
know about debugging support, but I read that it would be possible to 
debug plain POSIX apps with VS.

Debugging is not that important for me, as I currently want to build 
well known apps as bash, gnu make, gnu find etc. with cl.exe, just to 
verify that it works, and to be able to use cl.exe's warnings in 
comparison to gcc's warnings, just to possibly get the code more 
clean. I think it's better when it even works with several compilers.

Linking with gcc/ld is necessary for .so libs.

> Many questions ;o) maybe you want to try (after wgcc works ;o)) to only
> compile with wgcc, and manually link with ld and gather some experience
> in this direction.... I will try too!

Ok, will try with wgcc, too.

Martin

Re: [wgcc-dev] wgcc does not build

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

Hi!

First: I'm really really glad to get some feedback at last ;o) please
direct your mails to the int...@li... so
the mails get archived... I'll in any case CC you if you don't want to
subscribe.

The last lines are less interesting than the first errors ;o) could you
send me a complete output? How are you building, have you read the
INSTALL file? You could also attach the output from env. Which version
of Interix are you using, and which version of Windows.

I did never try to link with wgcc output with ld, why would you like to
do this? If it works, this could really be worth an extension. Does the
resulting binary depend on the microsoft runtime, or the interix
runtime. Can i use the windows api, and more important, can i use the
microsoft debugger (visual studio).

Many questions ;o) maybe you want to try (after wgcc works ;o)) to only
compile with wgcc, and manually link with ld and gather some experience
in this direction.... I will try too!

I today released wgcc 2.0.3, you may want to try it ;o)=20

-----Original Message-----
From: mkoeppe from UNIX Tools Community [mailto:mk...@gm...]=20
Sent: Tuesday, October 10, 2006 2:03 PM
To: Duft Markus
Subject: wgcc does not build

Hi Markus,

when trying to make wgcc, I get (the last lines):

DebugDumperTask.o(.text$_ZNSt14__simple_allocISt13_Rb_tree_nodeISt4pairI
KSsN4wgcc5Tasks21__tag_indicator_stateEEESt24__default_alloc_templateILb
1ELi0EEE8allocateEj+0x28):DebugDumperTask.cpp: undefined reference to
`std::__default_alloc_template<true, 0>::allocate(unsigned int)'
DumperTask.o(.text$_ZNSt14__simple_allocISt13_Rb_tree_nodeISt4pairIKSsbE
ESt24__default_alloc_templateILb1ELi0EEE10deallocateEPS4_j+0x24):DumperT
ask.cpp: undefined reference to `std::__default_alloc_template<true,
0>::deallocate(void*, unsigned int)'
DumperTask.o(.text$_ZNSt14__simple_allocISt13_Rb_tree_nodeISt4pairIKSsbE
ESt24__default_alloc_templateILb1ELi0EEE8allocateEj+0x28):DumperTask.cpp
: undefined reference to `std::__default_alloc_template<true,
0>::allocate(unsigned int)'
Utility.o(.text$_ZNSt14__simple_allocISt4pairIN9__gnu_cxx17__normal_iter
atorIPKcSsEES5_ESt24__default_alloc_templateILb1ELi0EEE10deallocateEPS6_
j+0x1a):Utility.cpp: undefined reference to
`std::__default_alloc_template<true, 0>::deallocate(void*, unsigned
int)'
Utility.o(.text$_ZNSs12_S_constructIN9__gnu_cxx17__normal_iteratorIPKcSs
EEEEPcT_S6_RKSaIcESt20forward_iterator_tag+0xce):Utility.cpp: undefined
reference to `std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::_Rep::_S_create(unsigned int,
std::allocator<char> const&)'
Utility.o(.text$_ZNSt14__simple_allocISt4pairIN9__gnu_cxx17__normal_iter
atorIPKcSsEES5_ESt24__default_alloc_templateILb1ELi0EEE8allocateEj+0x1e)
:Utility.cpp: undefined reference to
`std::__default_alloc_template<true, 0>::allocate(unsigned int)'
collect2: ld returned 1 exit status


I'm interested in wgcc, because I look for a smart replacement for
cc/c89, i.e. I want to use cl.exe instead of gcc for compilation, but
nevertheless use gnu ld to link to (and to create) interix's .so libs.
This doesn't seem to be the intent of wgcc, but: Is this possible with
wgcc, too? Or would it be worth an extension? I could help in testing
this.

Martin

[wgcc-dev] Wgcc 2.0.2 released.

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

wgcc is a cross-compiler tool primarily written for Microsoft's Interix.
Its primary purpose is to produce native Windows binaries (internally
using the Microsoft Tool chain), and to mimic the behaviour of the GNU
compiler collection. This means that wgcc understands many of GCC's
command line arguments, and in most cases delivers the same results as
expected, sometimes manipulating the underlying tool's input and output.

Even though wgcc was written for Interix only, it can be used on native
Windows (without Interix), and other Systems, like Cygwin. The only
restriction is that on Platforms other than Interix, only Windows style
paths are understood. With the release of version 2.0.1 this changed.
Now Cygwin too is able to convert paths correctly. On Interix (and now
Cygwin) wgcc automatically converts UNIX style paths to Windows style
ones (i.e. /wgcc to C:\SFU\wgcc).

wgcc abstracts away lots of inconveniences that are introduced by
building static libraries, shared libraries (DLL's) and executables with
any possible combination of those three. When using wgcc both static and
shared libraries behave exactly the same on Windows, and this makes tons
of defines unnecessary. The only thing that still has to be done is to
give all Data symbols (i.e. Variables) an import attribute
(__declspec(dllimport)) when using them (i.e. in the library header
files) in an executable. For a simple example take a look at the file
tests/shared.test inside the wgcc distribution.

In release 2.0.2 there are again some big changes: wgcc now recognizes
debug information in object files built using Visual C++ 2005. In this
version Microsoft does not output line number information anymore, on
which wgcc relied. The handling of Directories (Include directories,
Library directories) has been fixed. There was a small bug when
validating a directory. In version 2.0.1 .wgccrc defined _DEBUG in debug
builds. This is not the case anymore, now the pxwc.h header file defines
_DEBUG whenever using the pxwc memory profiler (PXWC_MEMORY_PROFILER is
defined). The context dump behaviour in verbose output has been fixed.
In version 2.0.1 the context was only dumped when all tasks succeeded.
Now the context gets dumped anyway, regardless of compilation success.
As of 2.0.2 the expand-paths feature is enabled by default in .wgccrc.

The handling of preprocessed files was improved in 2.0.2. In earlier
versions wgcc treated preprocessed sources the same as any other source
file, which is wrong, since the library-header header file (normally
pxwc.h) was included twice.

Since 2.0.2 wgcc is known to work with ccache and distcc, which brings
great performance improvements in some cases, an For d allows for
distirbuted compilation over networks. For more information on how to
build and use those two packages, feel free to contact mduft.

Since a few days, http://interix-wgcc.sf.net is finally online. It's
only a very small page, so that there is not an empty directory listing
anymore. Additionally while designing the web page, a new logo was
created, which can be seen on the homepage and the documentation front
page.

The pxwc library stayed mostly the same, except that it now provides a
"sleep" function. As written above, pxwc.h now defines _DEBUG whenever
PXWC_MEMORY_PROFILER is defined. This should be the only case when one
needs the debug runtime from Microsoft.

To continue improving wgcc and pxwc packages, we now need your help in
testing them. Please download wgcc and try to compile your software
using it. If something goes wrong please contact mduft or open an issue
using the Sourceforge Tracker at
http://sourceforge.net/tracker/?group_id=3D158081&atid=3D806404, or ask =
your
questions at the forums at
http://sourceforge.net/forum/?group_id=3D158081.

You can browse the Subversion Repository here:
http://svn.sourceforge.net/viewvc/interix-wgcc/trunks/

Documentation can be found here:
http://sourceforge.net/project/showfiles.php?group_id=3D158081&package_id=
=3D
203917&release_id=3D446943
Source Packages can be found here:
http://sourceforge.net/project/showfiles.php?group_id=3D158081&package_id=
=3D
177049&release_id=3D445894
The Patch for Libtool can be found here:
http://sourceforge.net/project/showfiles.php?group_id=3D158081&package_id=
=3D
196163&release_id=3D446510

[wgcc-dev] wgcc 2.0.1 released

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

wgcc is a cross-compiler tool primarily written for Microsoft's Interix.
Its primary purpose is to produce native Windows binaries  (internally
using the Microsoft Tool chain), and to mimic the behaviour of the GNU
compiler collection. This means that wgcc understands many  of GCC's
command line arguments, and in most cases delivers the same results as
expected, sometimes manipulating the underlying tool's input  and
output.

Even though wgcc was written for Interix only, it can be used on native
Windows (without Interix), and other Systems, like Cygwin. The only
restriction is that on Platforms other than Interix, only Windows style
paths are understood. With the release of version 2.0.1 this changed.
Now Cygwin too is able to convert paths correctly. On Interix (and now
Cygwin) wgcc automatically converts UNIX style paths to Windows style
ones (i.e. /wgcc to C:\SFU\wgcc).

wgcc abstracts away lots of inconveniences that are introduced by
building static libraries, shared libraries (DLL's) and executables with
any possible combination of those three. When using wgcc both static and
shared libraries behave exactly the same on Windows, and this makes
tons of defines unnecessary. The only thing that still has to be done is
to give all Data symbols (i.e. Variables) an import attribute
(__declspec(dllimport)) when using them (i.e. in the library header
files) in an executable. For a simple example take a look at the file
tests/shared.test inside the wgcc distribution.

wgcc version 2.0.1 changes some things that are not visible on the first
view. It acts a lot cleverer when searching for Libraries, and  linking
them together. Wgcc now detects conflicts between Runtime versions
automatically. This Feature is only available for libraries built  using
wgcc. When explicitly enabled, wgcc and pxwc together add capabilities
for profiling memory usage and memory leaks with no code changes  to
your programs. Of course you can add profiling function calls to your
code to get finer grained results. For more Information see the  current
Documentation.

To the pxwc library there have been some changes needed for memory
profiling support, and runtime conflict checking done by wgcc. Still
pxwc  includes only a small set of functions, so your help is needed to
find out which others to include. Just open a Feature Request at
http://sourceforge.net/tracker/?group_id=3D158081&atid=3D806407 and we =
will
try to add functionality as soon as possible.

The libtool 1.5.22 patch has been reviewed and improved. Currently still
four tests fail, but we're working hard to get those failures away.

To continue improving wgcc and pxwc packages, we now need your help in
testing them. Please download wgcc and try to compile your software
using it. If something goes wrong please contact mduft or open an issue
using the Sourceforge Tracker at
http://sourceforge.net/tracker/?group_id=3D158081&atid=3D806404, or ask =
your
questions at the forums at
http://sourceforge.net/forum/?group_id=3D158081.

You can browse the Subversion Repository here:
http://svn.sourceforge.net/viewvc/interix-wgcc/trunks/

Documentation can be found here:
http://sourceforge.net/project/showfiles.php?group_id=3D158081&package_id=
=3D
203917&release_id=3D446943
Source Packages can be found here:
http://sourceforge.net/project/showfiles.php?group_id=3D158081&package_id=
=3D
177049&release_id=3D445894
The Patch for Libtool can be found here:
http://sourceforge.net/project/showfiles.php?group_id=3D158081&package_id=
=3D
196163&release_id=3D446510

[wgcc-dev] Wgcc status report

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

Hey again!

Wgcc status report ;o) (this is rc4 with libtool patch from today):

PASS: cdemo-static.test
PASS: cdemo-make.test
PASS: cdemo-exec.test
PASS: demo-static.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
PASS: demo-unst.test
PASS: depdemo-static.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: depdemo-unst.test
PASS: mdemo-static.test
PASS: mdemo-make.test
PASS: mdemo-exec.test
PASS: mdemo-inst.test
PASS: mdemo-unst.test
PASS: cdemo-conf.test
PASS: cdemo-make.test
PASS: cdemo-exec.test
PASS: demo-conf.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
PASS: demo-unst.test
PASS: deplibs.test
PASS: depdemo-conf.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: depdemo-unst.test
PASS: mdemo-conf.test
PASS: mdemo-make.test
PASS: mdemo-exec.test
PASS: mdemo-inst.test
PASS: mdemo-unst.test
PASS: dryrun.test
PASS: demo-nofast.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
PASS: demo-unst.test
PASS: demo-pic.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-nopic.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: depdemo-nofast.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: depdemo-unst.test
PASS: cdemo-shared.test
PASS: cdemo-make.test
PASS: cdemo-exec.test
PASS: demo-shared.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
SKIP: hardcode.test
FAIL: build-relink.test
PASS: noinst-link.test
PASS: demo-unst.test
PASS: depdemo-shared.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
FAIL: build-relink2.test
PASS: depdemo-unst.test
PASS: mdemo-shared.test
PASS: mdemo-make.test
PASS: mdemo-exec.test
PASS: mdemo-inst.test
PASS: mdemo-unst.test
PASS: assign.test
PASS: link.test
PASS: link-2.test
PASS: nomode.test
PASS: quote.test
PASS: sh.test
PASS: suffix.test
PASS: pdemo-conf.test
PASS: pdemo-make.test
PASS: pdemo-exec.test
PASS: pdemo-inst.test
PASS: mdemo-conf.test
PASS: mdemo-make.test
PASS: mdemo2-conf.test
PASS: mdemo2-make.test
FAIL: mdemo2-exec.test
PASS: duplicate_members.test
PASS: link-order.test
PASS: tagdemo-static.test
PASS: tagdemo-make.test
PASS: tagdemo-exec.test
PASS: tagdemo-conf.test
PASS: tagdemo-make.test
PASS: tagdemo-exec.test
PASS: tagdemo-shared.test
PASS: tagdemo-make.test
PASS: tagdemo-exec.test
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
3 of 102 tests failed
(1 tests were not run)
Please report to bug...@gn...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This looks *very* cool ;o) For the tests failed: hardcode will never
work, thats clear (fails with gcc too). The other three, i really have
no idea there. Mdemo2 fails only half, as far as i've seen the static
version executes OK. I think the error is, that libltld allways tries to
dlopen the static library, not the shared one, but i can't figure it out
(i hate dlpreopening ;o)) (and i can't read my own changed code
anymore... *argl* ;o))

I also tested gcc, to see if my changes influenced it somehow. Only
hardcode.test failed, and thats ok (it does without my patch too) ;o).

I now changed the hardcode.test to skip on all interix platforms for
now.

Cheers, Markus

Re: [wgcc-dev] Dlpreopen on windows

[Ralf W. <Ral...@gm...>]

Hello Markus,

* Duft Markus wrote on Mon, Sep 25, 2006 at 05:18:21PM CEST:
> 
> Libtool generates a symbol table on the fly which it then compiles and
> links in, correct?
> That symbols table contains both .text and .data symbols. There is no
> problem with .text symbols so far ;o)
> As i saw the ....nmS file uses a one letter prefix to identify the type
> of symbol. My mdemo.nmS for exmaple has three types:
> 
>  T	.text i think, so all functions
>  B	.bss (??) i think, initialized data
>  C	.data (??) uninitialized data?

The types are derived from how `nm' on unices shows the ELF sections:
 "B" The symbol is in the uninitialized data section (known as BSS).
 "C" The  symbol  is common.  Common symbols are uninitialized data.  When linking,
     multiple common symbols may appear with the  same  name.   If  the  symbol  is
     defined anywhere, the common symbols are treated as undefined references.
 "D" The symbol is in the initialized data section.
 "T" The symbol is in the text (code) section.

We should probably change the mdemo test to not only test common symbols
(they are the least important), but to test initialized (to null and to
non-null) symbols.  Oh well, the stresstest in HEAD is useful for that.

> P.S.: the windows compiler does not define data symbols in object files
> if they are not referenced at least once in that object file. So the
> libtool mdemo/foo(1|2).c nothing variable is missing in the objects
> unless i initialize them with something (0 in my case...).

Hmm.  Is there a command line option to make it emit the common symbol?

Cheers,
Ralf

Re: [wgcc-dev] Wgcc status report

[Ralf W. <Ral...@gm...>]

Hello Markus,

I would prefer if you did not send messages to the libtool list twice,
did not send messages including large patches to the libtool list
(that's what the libtool-patches list is for), and I would also
personally prefer if your announcement frequency were more that of an,
err, announcement.  Users interested in every next step can still read
your interix-wgcc-developer and/or the libtool-patches list.

* Duft Markus wrote on Tue, Sep 26, 2006 at 09:44:10AM CEST:

> FAIL: build-relink.test
> FAIL: build-relink2.test
> FAIL: mdemo2-exec.test

> This looks *very* cool ;o) For the tests failed: hardcode will never
> work, thats clear (fails with gcc too).

Wrong.  The hardcode test tests that the settings in libtool.m4 conform
to expected behavior.  The settings are false, thus the failure.

> I now changed the hardcode.test to skip on all interix platforms for
> now.

So you paper over the issue.

> The other three, i really have
> no idea there. Mdemo2 fails only half, as far as i've seen the static
> version executes OK. I think the error is, that libltld allways tries to
> dlopen the static library, not the shared one, but i can't figure it out
> (i hate dlpreopening ;o)) (and i can't read my own changed code
> anymore... *argl* ;o))
> 
> I also tested gcc, to see if my changes influenced it somehow. Only
> hardcode.test failed, and thats ok (it does without my patch too) ;o).

If you desire to get your changes into GNU Libtool, you should strive to
- keep system-specific changes out of ltmain.sh, and out of all the
  tests as much as is sanely possible.  Remember the tests should also
  demonstrate what users are expected to do, so work hard to keep the
  number of preprocessor conditionals down to a minimum; and to
- not break any other system with your patches; that is a show-stopper.

Using `uname' in ltmain.sh is wrong, that breaks for cross-compilation.
Some of the comments in the patch you posted are wrong (they are copy
and pasted from elsewhere, but do not match the pasted code).

I would like to encourage you to port your patch to CVS Libtool, as it
has a better testsuite.  In case that is too much work for you, you may
anyway want to try its testsuite with
  ./tests/testsuite LIBTOOL=/path/to/1.5.22/build/libtool -k libtool \
                    -k stresstest

Hope that helps.

Cheers,
Ralf

[wgcc-dev] Dlpreopen on windows

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

Hey together ;o)

I again played a little with dlpreopening on windows (with wgcc). Now i
again know why it didn't work ;o)

Libtool generates a symbol table on the fly which it then compiles and
links in, correct?
That symbols table contains both .text and .data symbols. There is no
problem with .text symbols so far ;o)
As i saw the ....nmS file uses a one letter prefix to identify the type
of symbol. My mdemo.nmS for exmaple has three types:

 T	.text i think, so all functions
 B	.bss (??) i think, initialized data
 C	.data (??) uninitialized data?

Please correct me if i'm wrong ;o). Now on windows, it would be cool
(and neccessary) to know if a symbol comes from a shared library (since
i then need to import it.). The extern definition of data symbols should
have a __declspec(dllimport) where apropriate. With wgcc it would be a
little easier, since wgcc automatically generates the "__imp_" pointers
(needed for __declspec(dllimport) to work) for all static libraries too,
so one would not have to differentiate (but this would *only* work for
wgcc then...).

I now changed libtool a little (quick and dirty hack ;o) to be:

global_symbol_to_cdecl=3D"awk '{ if(\$1 !=3D \"T\") { print \"extern
__declspec\(dllimport\) int \" \$3 \";\" } else { print  "extern int \"
\$3 \";\" } }'"

This puts another problem into place: this does *not* compile with the
microsoft compiler *except* when using C++. For that reason i added the
-xc++ option to the compiler command.

Now i ran mdemo test ok with wgcc ;o)

Any thoughts on this?

Cheers, Markus

P.S.: the windows compiler does not define data symbols in object files
if they are not referenced at least once in that object file. So the
libtool mdemo/foo(1|2).c nothing variable is missing in the objects
unless i initialize them with something (0 in my case...).

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

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

=20

-----Original Message-----
From: Jerker B=E4ck [mailto:jer...@te...]=20
Sent: Sunday, September 24, 2006 6:25 PM
To: Duft Markus
Subject: RE: Hey ho....

Now I get it - you designed wgcc for building Win32 binaries, is that =
so? A tool to build for example FireFox on Windows using unix makefile =
tools with MS tools, right? Is wgcc really unable to build posix apps in =
current design? Did you ever consider using it to enhancing the cc =
script?=20

I would think building of posix apps is the real challenge here. Due to =
lack of proper information there are so many opinions how this should be =
made, what is possible and what is NOT possible. For me, the problem is =
that cc sometimes fails or doing the wrong thing (especially in =
configure scripts).
So it ends up in a tedious checkups of config.h and makefiles. As for =
cc, I found some bugs in SUA cc (mainly in the C++ part) and missing =
some compatibility with gcc and GNU. Even if the script is a really nice =
piece of work, it could be improved greatly. Problem is, not being a =
unix guy, the shell script insights is not one of my skills, nor do it =
interest me much either. Leaving us to a conclusion: A user maintained =
build tool for posix builds using MSC. I think wgcc could be an =
excellent candidate to that!

> port of the GNU libc (not c++) to win32 (_not_ interix)
You have that in cygwin (in contrast to mingw which mimics MSCRT and use =
native Win32) - checkout the cygwin source - you could probably build it =
with wgcc.

If you consider the complexity in SUA with posix, mixed mode, posix DLL, =
BSD libc DLL, safe CRT and MS C++ you surely could understand why I =
mention the need. I just hate the way the MS developers implemented the =
SDK build resources (/usr/lib). For example the start-up code you got: =
crt0.o crtdll.o crtexe.o crti.o mixcrt0.o safecrt0.o - all with some =
very secret holy code.
which one to choose? It's bound to get all sorts of dependency problems.

I will test wgcc as you proposed and intended.=20
I will also experiment with different builds - i.e. mixed mode. When I =
get a working posix app I could start testing using it as a cc =
replacement. I suspect this would require design changes - what are your =
reactions/interest of that?


Jerker

________________________________

From: Duft Markus [mailto:Mar...@sa...]
Sent: Sunday, September 24, 2006 10:16 AM
To: Jerker B=E4ck; int...@li...
Subject: AW: Hey ho....


Hi!
=20
You really should _not_ install wgcc in /usr/local since then
/usr/local/include would be in the include path, and confuse cl.exe, =
since
those are _wrong_ headers.
=20
And you should realize, that wgcc really has nothing to do with posix =
builds
or anything. wgcc is a litlle tool to produce _native_ executables, =
means
there is no posix there, except when using the pxwc library. Then there =
is
just a bunch of functions so that the posix names are available on =
native
win32.
=20
in your .wgccrc you can specify the paths.c, paths.c++ and paths.linker. =
on
my system this is (detected automatically for a visual studio install):
=20
paths.c =3D /wamas/libtool/wgcc/installed/include
paths.c +=3D /dev/fs/C/vs7/Vc7/include
paths.c +=3D /def/fs/C7vs7/Vc7/PlatformSDK/include
paths.c++ =3D /wamas/libtool/wgcc/installed/include
paths.c++ +=3D /dev/fs/C/vs7/Vc7/include
paths.c++ +=3D /def/fs/C7vs7/Vc7/PlatformSDK/include
paths.linker =3D /wamas/libtool/wgcc/installed/lib
paths.linker +=3D /dev/fs/C/vs7/Vc7/lib
paths.linker +=3D /def/fs/C7vs7/Vc7/PlatformSDK/lib
=20
you should set this to something similar. In my opinion there is really =
no
need to port _anything_. the only thing that would be cool is a port of =
the
GNU libc (not c++) to win32 (_not_ interix).
=20
wgcc really does something different than cc. look at wcc from
interopsystems. this one should do something similar as wgcc. there is =
no
sense in even _thinking_ about cc when speaking of wgcc.
=20
Cheers, Markus

________________________________

Von: Jerker B=E4ck [mailto:jer...@te...]
Gesendet: Sa 23.09.2006 16:06
An: Duft Markus
Betreff: RE: Hey ho....



> Your .wgccrc is corrupt i think
No, I just have not specified the location of Win32 headers and libs
I realized that after a while - anyway here's the files

In my case I would specify the headers and libs from the Windows 2003 =
SP1
platform SDK. The VS 2003 PlatformSDK folder is outdated and the one =
shipped
with VS 2005 is the same as the SDK - I deleted both folders (which is
recommended BTW).

My path includes a complete set of MS tools and I also specified the
C89_COMPILER and C89_LINKER macros used in the cc script. The advantage =
of
using tools from the Windows DDK is that the installation is designed to =
be
used standalone and have some extra goodies (i.e. prefast debug builds).

Struggling with wgcc I run into some problems with SUA MS C++ (again). =
Since
all libs are release builds in SUA (without any debugging info), it's =
very
difficult to build debug builds of the app in question (not to even =
mention
the infamous VSAddin posix debugger). The library is also incomplete
compared with the original in VS 2005. So this led me to several =
attempts to
do a basic port of the MS C++ library (version 7.1 most preferable). I'm
tempted to get on with it again.

Any thoughts about this?

________________________________

From: Duft Markus [mailto:Mar...@sa...]
Sent: Saturday, September 23, 2006 10:42 AM
To: Jerker B=E4ck; int...@li...
Subject: AW: Hey ho....

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

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

Yes, correctly. The thing is that a POSIX app really is nothing =
different than a win32 native app, except that it uses another runtime =
library with, as you said, secret holy code, which brings lots of mess =
with it. Building native win32 apps is the mucch cleaner and more =
desireable way of doing it. For the ability to use ansi function names =
in C when using wgcc, there is pxwc which is a small, and _open source_ =
library to define some ansi function names and other stuff for win32 =
apps. It even does some path conversion: whenever you access an =
environment variable that contains a unix style path, pxwc converts it =
to a windows style path.
I don't think that building win32 and posix apps as cc does is =
"compatible" i think this would be a great mess.... ;o) but maybe you'd =
like to start out making some kind of "port" of wgcc to build posix apps =
(allthough i think it's really senseless...)

Btw. Please write to int...@li... in the =
future, so the mails get archived ;o)

Cheers, Markus

-----Original Message-----
From: Jerker B=E4ck [mailto:jer...@te...]=20
Sent: Sunday, September 24, 2006 6:25 PM
To: Duft Markus
Subject: RE: Hey ho....

Now I get it - you designed wgcc for building Win32 binaries, is that =
so? A tool to build for example FireFox on Windows using unix makefile =
tools with MS tools, right? Is wgcc really unable to build posix apps in =
current design? Did you ever consider using it to enhancing the cc =
script?=20

I would think building of posix apps is the real challenge here. Due to =
lack of proper information there are so many opinions how this should be =
made, what is possible and what is NOT possible. For me, the problem is =
that cc sometimes fails or doing the wrong thing (especially in =
configure scripts).
So it ends up in a tedious checkups of config.h and makefiles. As for =
cc, I found some bugs in SUA cc (mainly in the C++ part) and missing =
some compatibility with gcc and GNU. Even if the script is a really nice =
piece of work, it could be improved greatly. Problem is, not being a =
unix guy, the shell script insights is not one of my skills, nor do it =
interest me much either. Leaving us to a conclusion: A user maintained =
build tool for posix builds using MSC. I think wgcc could be an =
excellent candidate to that!

> port of the GNU libc (not c++) to win32 (_not_ interix)
You have that in cygwin (in contrast to mingw which mimics MSCRT and use =
native Win32) - checkout the cygwin source - you could probably build it =
with wgcc.

If you consider the complexity in SUA with posix, mixed mode, posix DLL, =
BSD libc DLL, safe CRT and MS C++ you surely could understand why I =
mention the need. I just hate the way the MS developers implemented the =
SDK build resources (/usr/lib). For example the start-up code you got: =
crt0.o crtdll.o crtexe.o crti.o mixcrt0.o safecrt0.o - all with some =
very secret holy code.
which one to choose? It's bound to get all sorts of dependency problems.

I will test wgcc as you proposed and intended.=20
I will also experiment with different builds - i.e. mixed mode. When I =
get a working posix app I could start testing using it as a cc =
replacement. I suspect this would require design changes - what are your =
reactions/interest of that?


Jerker

________________________________

From: Duft Markus [mailto:Mar...@sa...]
Sent: Sunday, September 24, 2006 10:16 AM
To: Jerker B=E4ck; int...@li...
Subject: AW: Hey ho....


Hi!
=20
You really should _not_ install wgcc in /usr/local since then
/usr/local/include would be in the include path, and confuse cl.exe, =
since
those are _wrong_ headers.
=20
And you should realize, that wgcc really has nothing to do with posix =
builds
or anything. wgcc is a litlle tool to produce _native_ executables, =
means
there is no posix there, except when using the pxwc library. Then there =
is
just a bunch of functions so that the posix names are available on =
native
win32.
=20
in your .wgccrc you can specify the paths.c, paths.c++ and paths.linker. =
on
my system this is (detected automatically for a visual studio install):
=20
paths.c =3D /wamas/libtool/wgcc/installed/include
paths.c +=3D /dev/fs/C/vs7/Vc7/include
paths.c +=3D /def/fs/C7vs7/Vc7/PlatformSDK/include
paths.c++ =3D /wamas/libtool/wgcc/installed/include
paths.c++ +=3D /dev/fs/C/vs7/Vc7/include
paths.c++ +=3D /def/fs/C7vs7/Vc7/PlatformSDK/include
paths.linker =3D /wamas/libtool/wgcc/installed/lib
paths.linker +=3D /dev/fs/C/vs7/Vc7/lib
paths.linker +=3D /def/fs/C7vs7/Vc7/PlatformSDK/lib
=20
you should set this to something similar. In my opinion there is really =
no
need to port _anything_. the only thing that would be cool is a port of =
the
GNU libc (not c++) to win32 (_not_ interix).
=20
wgcc really does something different than cc. look at wcc from
interopsystems. this one should do something similar as wgcc. there is =
no
sense in even _thinking_ about cc when speaking of wgcc.
=20
Cheers, Markus

________________________________

Von: Jerker B=E4ck [mailto:jer...@te...]
Gesendet: Sa 23.09.2006 16:06
An: Duft Markus
Betreff: RE: Hey ho....



> Your .wgccrc is corrupt i think
No, I just have not specified the location of Win32 headers and libs
I realized that after a while - anyway here's the files

In my case I would specify the headers and libs from the Windows 2003 =
SP1
platform SDK. The VS 2003 PlatformSDK folder is outdated and the one =
shipped
with VS 2005 is the same as the SDK - I deleted both folders (which is
recommended BTW).

My path includes a complete set of MS tools and I also specified the
C89_COMPILER and C89_LINKER macros used in the cc script. The advantage =
of
using tools from the Windows DDK is that the installation is designed to =
be
used standalone and have some extra goodies (i.e. prefast debug builds).

Struggling with wgcc I run into some problems with SUA MS C++ (again). =
Since
all libs are release builds in SUA (without any debugging info), it's =
very
difficult to build debug builds of the app in question (not to even =
mention
the infamous VSAddin posix debugger). The library is also incomplete
compared with the original in VS 2005. So this led me to several =
attempts to
do a basic port of the MS C++ library (version 7.1 most preferable). I'm
tempted to get on with it again.

Any thoughts about this?

________________________________

From: Duft Markus [mailto:Mar...@sa...]
Sent: Saturday, September 23, 2006 10:42 AM
To: Jerker B=E4ck; int...@li...
Subject: AW: Hey ho....

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

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

Hi!
=20
You really should _not_ install wgcc in /usr/local since then =
/usr/local/include would be in the include path, and confuse cl.exe, =
since those are _wrong_ headers.
=20
And you should realize, that wgcc really has nothing to do with posix =
builds or anything. wgcc is a litlle tool to produce _native_ =
executables, means there is no posix there, except when using the pxwc =
library. Then there is just a bunch of functions so that the posix names =
are available on native win32.
=20
in your .wgccrc you can specify the paths.c, paths.c++ and paths.linker. =
on my system this is (detected automatically for a visual studio =
install):
=20
paths.c =3D /wamas/libtool/wgcc/installed/include
paths.c +=3D /dev/fs/C/vs7/Vc7/include
paths.c +=3D /def/fs/C7vs7/Vc7/PlatformSDK/include
paths.c++ =3D /wamas/libtool/wgcc/installed/include
paths.c++ +=3D /dev/fs/C/vs7/Vc7/include
paths.c++ +=3D /def/fs/C7vs7/Vc7/PlatformSDK/include
paths.linker =3D /wamas/libtool/wgcc/installed/lib
paths.linker +=3D /dev/fs/C/vs7/Vc7/lib
paths.linker +=3D /def/fs/C7vs7/Vc7/PlatformSDK/lib
=20
you should set this to something similar. In my opinion there is really =
no need to port _anything_. the only thing that would be cool is a port =
of the GNU libc (not c++) to win32 (_not_ interix).
=20
wgcc really does something different than cc. look at wcc from =
interopsystems. this one should do something similar as wgcc. there is =
no sense in even _thinking_ about cc when speaking of wgcc.
=20
Cheers, Markus

________________________________

Von: Jerker B=E4ck [mailto:jer...@te...]
Gesendet: Sa 23.09.2006 16:06
An: Duft Markus
Betreff: RE: Hey ho....



> Your .wgccrc is corrupt i think
No, I just have not specified the location of Win32 headers and libs
I realized that after a while - anyway here's the files

In my case I would specify the headers and libs from the Windows 2003 =
SP1
platform SDK. The VS 2003 PlatformSDK folder is outdated and the one =
shipped
with VS 2005 is the same as the SDK - I deleted both folders (which is
recommended BTW).

My path includes a complete set of MS tools and I also specified the
C89_COMPILER and C89_LINKER macros used in the cc script. The advantage =
of
using tools from the Windows DDK is that the installation is designed to =
be
used standalone and have some extra goodies (i.e. prefast debug builds).

Struggling with wgcc I run into some problems with SUA MS C++ (again). =
Since
all libs are release builds in SUA (without any debugging info), it's =
very
difficult to build debug builds of the app in question (not to even =
mention
the infamous VSAddin posix debugger). The library is also incomplete
compared with the original in VS 2005. So this led me to several =
attempts to
do a basic port of the MS C++ library (version 7.1 most preferable). I'm
tempted to get on with it again.

Any thoughts about this?

________________________________

From: Duft Markus [mailto:Mar...@sa...]
Sent: Saturday, September 23, 2006 10:42 AM
To: Jerker B=E4ck; int...@li...
Subject: AW: Hey ho....

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

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

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

Hey again!
=20
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))
=20
wgcc supports using third party C++ runtimes (stdcxx was used here, but =
anything else may be subtituted in instead, see .wgccrc (stdcxx.* =
options)).
=20
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.
=20
I'll look into adding a INSTALL file, or adding instructions to the =
docs.
=20
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:
=20
confix.py --boo
=20
inside the wgcc source tree. if you want to enable libtool use:
=20
confix.py --boo --use-libtool
=20
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

[wgcc-dev] Wgcc 2.0 RC2 released.

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

wgcc is a cross-compiler tool primarily written for Microsoft's Interix.
Its primary purpose is to produce native Windows binaries (internally
using the Microsoft Tool chain), and to mimic the behaviour of the GNU
compiler collection. This means that wgcc understands many of GCC's
command line arguments, and in most cases delivers the same results as
expected, sometimes manipulating the underlying tool's input and output.

Even though wgcc was written for Interix only, it can be used on native
Windows (without Interix), and other Systems, like Cygwin. The only
restriction is that on Platforms other than Interix, only Windows style
paths are understood. This will change in the future for Cygwin, and/or
others. On Interix wgcc automatically converts UNIX style paths to
Windows style ones (i.e. /wgcc to C:\SFU\wgcc).

wgcc abstracts away lots of inconveniences that are introduced by
building static libraries, shared libraries (DLL's) and executables with
any possible combination of those three. When using wgcc both static and
shared libraries behave exactly the same on Windows, and this makes tons
of defines unnecessary. The only thing that still has to be done is to
give all Data symbols (i.e. Variables) an import attribute
(__declspec(dllimport)) when using them (i.e. in the library header
files) in an executable. For a simple example take a look at the file
tests/shared.test inside the wgcc distribution.

The Release Candidate 2 of wgcc is more or less a bug fix release
compared to RC1. There is not too much new. Bug fixes include a nearly
complete rewrite of the Import Trampoline gererator and the Export
Definition generator, since those two worked very bad for C, but only
for C++.

pxwc has been reviewed and changed a little, to not include that many
defines, where inlined static functions are possible. Still pxwc
currently includes only a small set of functions, so your help is needed
to find out which others to include. Just open a Feature Request at
http://sourceforge.net/tracker/?group_id=3D158081&atid=3D806407 and we =
will
try to add functionality as soon as possible.

To continue improving wgcc and pxwc packages, we now need your help in
testing them. Please download wgcc and try to compile your software
using it. If something goes wrong please contact mduft or open an issue
using the Sourceforge Tracker at
http://sourceforge.net/tracker/?group_id=3D158081&atid=3D806404, or ask =
your
questions at the forums at
http://sourceforge.net/forum/?group_id=3D158081.

You can browse the Subversion Repository here:
http://svn.sourceforge.net/viewvc/interix-wgcc/trunks/

Documentation can be found here:
http://sourceforge.net/project/showfiles.php?group_id=3D158081&package_id=
=3D
203917&release_id=3D446943
Source Packages can be found here:
http://sourceforge.net/project/showfiles.php?group_id=3D158081&package_id=
=3D
177049&release_id=3D445894
The Patch for Libtool can be found here:
http://sourceforge.net/project/showfiles.php?group_id=3D158081&package_id=
=3D
196163&release_id=3D446510

Cheers, Markus

[wgcc-dev] wgcc 2.0 RC1 released

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

Hi again!
=20
For all interested in native Windows binaries built with Autotools and
mnay other interesting things:
=20
wgcc is a cross-compiler tool primarily written for Microsoft's Interix.
Its primary purpose is to produce native Windows binaries (internally
using the Microsoft Tool chain), and to mimic the behaviour of the GNU
compiler collection. This means that wgcc understands many of GCC's
command line arguments, and in most cases delivers the same results as
expected, sometimes manipulating the underlying tool's input and output.
=20
Even though wgcc was written for Interix only, it can be used on native
Windows (without Interix), and other Systems, like Cygwin. The only
restriction is that on Platforms other than Interix, only Windows style
paths are understood. This will change in the future for Cygwin, and/or
others. On Interix wgcc automatically converts UNIX style paths to
Windows style ones (i.e. /wgcc to C:\SFU\wgcc).
=20
wgcc abstracts away lots of inconveniences that are introduced by
building static libraries, shared libraries (DLL's) and executables with
any possible combination of those three. When using wgcc both static and
shared libraries behave exactly the same on Windows, and this makes tons
of defines unnecessary. The only thing that still has to be done is to
give all Data symbols (i.e. Variables) an import attribute
(__declspec(dllimport)) when using them (i.e. in the library header
files) in an executable. For a simple example take a look at the file
tests/shared.test inside the wgcc distribution.
=20
The Release Candidate 1 of wgcc has a completely rewritten Configuration
File parser, which allows for faster and safer parsing; now adding the
ability to include empty directives in configuration files. This could
be something like "paths.c++ =3D" to unset all C++ search directories.
=20
Also the ability to automatically generate export definitions and import
trampolines for mixing static and shared libraries with executables has
been reviewed and improved. This did not change the behaviour of wgcc
regarding the 2.0-pre.x versions, but only speeded it up a little.
=20
pxwc, the accompanying library for wgcc allows further abstraction for C
code, allowing use of the ANSI function names (i.e. without the leading
"_"). pxwc currently includes only a small set of functions, so your
help is needed to find out which others to include. Just open a Feature
Request at =
http://sourceforge.net/tracker/?group_id=3D158081&atid=3D806407
and we will try to add functionality as soon as possible.
=20
Using the patch provided for GNU Libtool, wgcc can be used with many
Open Source packages. After patching and installing Libtool, simply
bootstrap the package in question, configure (set CC, CXX and LD to
"wgcc") and build. The configure Script should tell that the linker in
use is the "Interix to Win32 cross linker (wgcc)".
=20
Since the version jump to 2.x wgcc now resides in the Sourceforge
Subversion Repository. The CVS Repository still continues to contain
previous wgcc versions (0.x).
=20
To continue improving wgcc and pxwc packages, we now need your help in
testing them. Please download wgcc and try to compile you software using
it. If something goes wrong please contact mduft or open an issue using
the Sourceforge Tracker at
http://sourceforge.net/tracker/?group_id=3D158081&atid=3D806404, or ask =
your
questions at the forums at
http://sourceforge.net/forum/?group_id=3D158081.
=20
You can browse the Subversion Repository here:
http://svn.sourceforge.net/viewvc/interix-wgcc/trunks/
=20
Documentation can be found here:
http://sourceforge.net/project/showfiles.php?group_id=3D158081&package_id=
=3D
203917&release_id=3D446943
Source Packages can be found here:
http://sourceforge.net/project/showfiles.php?group_id=3D158081&package_id=
=3D
177049&release_id=3D445894
The Patch for Libtool can be found here:
http://sourceforge.net/project/showfiles.php?group_id=3D158081&package_id=
=3D
196163&release_id=3D446510

[wgcc-dev] wgcc-2.0-pre.7

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

Hi everybody!

i'm proud to announce that wgcc-2.0-pre.7 and it's documentation have
been released. This version is close to the first RC and is capable of
building (with little or no modifications) OpenLDAP, OpenSSL, libtool,
zlib, Berkeley DB, expat, gettext, libiconv, pkgconfig, glib, libIDL,
popt, ORBit2, and many others. Additionally now the Apache stdcxx
project is fully supported. A Patch for GNU Libtool is available to give
it support for wgcc (the work on this support is finished to about 80%).
For any Questions, feel free to mail me!=20

Cheers, Markus

[wgcc-dev] wgcc tuning...

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

ok, after some tuning, no more skips, and some less fails.
=20
PASS: cdemo-static.test
PASS: cdemo-make.test
PASS: cdemo-exec.test
PASS: demo-static.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
PASS: demo-unst.test
PASS: depdemo-static.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: depdemo-unst.test
PASS: mdemo-static.test
PASS: mdemo-make.test
FAIL: mdemo-exec.test
FAIL: mdemo-inst.test
PASS: mdemo-unst.test
PASS: cdemo-conf.test
PASS: cdemo-make.test
PASS: cdemo-exec.test
PASS: demo-conf.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
PASS: demo-unst.test
PASS: deplibs.test
PASS: depdemo-conf.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: depdemo-unst.test
PASS: mdemo-conf.test
PASS: mdemo-make.test
FAIL: mdemo-exec.test
FAIL: mdemo-inst.test
PASS: mdemo-unst.test
PASS: dryrun.test
PASS: demo-nofast.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
PASS: demo-unst.test
PASS: demo-pic.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-nopic.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: depdemo-nofast.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: depdemo-unst.test
PASS: cdemo-shared.test
PASS: cdemo-make.test
PASS: cdemo-exec.test
PASS: demo-shared.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
FAIL: hardcode.test
FAIL: build-relink.test
PASS: noinst-link.test
PASS: demo-unst.test
PASS: depdemo-shared.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
FAIL: build-relink2.test
PASS: depdemo-unst.test
PASS: mdemo-shared.test
PASS: mdemo-make.test
FAIL: mdemo-exec.test
FAIL: mdemo-inst.test
PASS: mdemo-unst.test
PASS: assign.test
PASS: link.test
PASS: link-2.test
PASS: nomode.test
PASS: quote.test
PASS: sh.test
PASS: suffix.test
PASS: pdemo-conf.test
PASS: pdemo-make.test
PASS: pdemo-exec.test
PASS: pdemo-inst.test
PASS: mdemo-conf.test
PASS: mdemo-make.test
PASS: mdemo2-conf.test
PASS: mdemo2-make.test
FAIL: mdemo2-exec.test
PASS: duplicate_members.test
FAIL: link-order.test
PASS: tagdemo-static.test
PASS: tagdemo-make.test
PASS: tagdemo-exec.test
PASS: tagdemo-conf.test
PASS: tagdemo-make.test
PASS: tagdemo-exec.test
PASS: tagdemo-shared.test
PASS: tagdemo-make.test
PASS: tagdemo-exec.test
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
11 of 103 tests failed
Please report to bug...@gn...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
will be in 2.0-pre.4, but not today anymore....
=20
Cheers, Markus

[wgcc-dev] wgcc critical update

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

hey everybody.
=20
there was a really bad, bad, bad malloc in all 2.0-pre.x versions, which
is fixed in wgcc-2.0-pre.3. there was one byte missing in the alloc,
which caused unpredictable behaviour (core dumps) when processing
command outputs.
=20
i.e. when cl.exe & co. didn't output anything, everything went ok ;o///
=20
if you use one of those versions, please upgrade, distfile is @
sourceforge as usual...
=20
Additionally the libtool patch for 2.x is available now on sourceforge
too. There are a few tests that are now possible with wgcc 2.x, which
were impossible to get working with 1.x. This depends mostly on the new
export behaviour, which does NOT export variable from external libraries
anymore (i.e. each library linked in is private to the resulting binary
image, which is the best behaviour ;o))
=20
some current test results with the sources currently on sourceforge are:
=20
PASS: cdemo-static.test
PASS: cdemo-make.test
PASS: cdemo-exec.test
PASS: demo-static.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
PASS: demo-unst.test
PASS: depdemo-static.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: depdemo-unst.test
PASS: mdemo-static.test
FAIL: mdemo-make.test
SKIP: mdemo-exec.test
SKIP: mdemo-inst.test
PASS: mdemo-unst.test
PASS: cdemo-conf.test
PASS: cdemo-make.test
PASS: cdemo-exec.test
PASS: demo-conf.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
PASS: demo-unst.test
PASS: deplibs.test
PASS: depdemo-conf.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: depdemo-unst.test
PASS: mdemo-conf.test
FAIL: mdemo-make.test
SKIP: mdemo-exec.test
SKIP: mdemo-inst.test
PASS: mdemo-unst.test
FAIL: dryrun.test
PASS: demo-nofast.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
PASS: demo-unst.test
PASS: demo-pic.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-nopic.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: depdemo-nofast.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
PASS: depdemo-unst.test
PASS: cdemo-shared.test
PASS: cdemo-make.test
PASS: cdemo-exec.test
PASS: demo-shared.test
PASS: demo-make.test
PASS: demo-exec.test
PASS: demo-inst.test
FAIL: hardcode.test
FAIL: build-relink.test
PASS: noinst-link.test
PASS: demo-unst.test
PASS: depdemo-shared.test
PASS: depdemo-make.test
PASS: depdemo-exec.test
PASS: depdemo-inst.test
FAIL: build-relink2.test
PASS: depdemo-unst.test
PASS: mdemo-shared.test
FAIL: mdemo-make.test
SKIP: mdemo-exec.test
SKIP: mdemo-inst.test
PASS: mdemo-unst.test
PASS: assign.test
PASS: link.test
PASS: link-2.test
PASS: nomode.test
PASS: quote.test
PASS: sh.test
PASS: suffix.test
PASS: pdemo-conf.test
PASS: pdemo-make.test
PASS: pdemo-exec.test
PASS: pdemo-inst.test
PASS: mdemo-conf.test
FAIL: mdemo-make.test
PASS: mdemo2-conf.test
SKIP: mdemo2-make.test
SKIP: mdemo2-exec.test
PASS: duplicate_members.test
FAIL: link-order.test
PASS: tagdemo-static.test
PASS: tagdemo-make.test
PASS: tagdemo-exec.test
PASS: tagdemo-conf.test
PASS: tagdemo-make.test
PASS: tagdemo-exec.test
PASS: tagdemo-shared.test
PASS: tagdemo-make.test
PASS: tagdemo-exec.test
FAIL: f77demo-static.test
SKIP: f77demo-make.test
SKIP: f77demo-exec.test
FAIL: f77demo-conf.test
SKIP: f77demo-make.test
SKIP: f77demo-exec.test
FAIL: f77demo-shared.test
SKIP: f77demo-make.test
SKIP: f77demo-exec.test
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
12 of 98 tests failed
(14 tests were not run)
Please report to bug...@gn...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
all the libtool mdemo tests still fail, because there is still a problem
with dlopen and static libraries, i.e. dlpreopening, because the libtool
generated symbols conflict with some assembler code that wgcc generates.
this will be the next thing to work on, so if there is a solution for
this, it should be available in a few days....
=20
for the hardcode test -> this is simply not possible on windows........
for the relink tests -> i have really no idea here yet......
=20
the test results look pretty much better than in version 1.x, except
that in v1 building the mdemo tests went ok, so there seem to be more
fails and skips now, but thats really not true, because 1.x failed one
step later (i did much patching there...) ;o)
=20
that the f77 tests failed..... i think this is ok ;o) wgcc does not know
fortran, i forgot to disable those tests....
=20
Cheers, Markus Duft

[wgcc-dev] wgcc-0.5.7 and ucl-1.1

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

Hey!
=20
wgcc 0.5.7 and ucl 1.1 have been released and are available for
download. ucl was previously integrated in the wgcc package, and is a
little helper (compiler and linker wrappers ucl.exe and ulink.exe) which
include the wgcc's pxwc library even when not building with wgcc, and do
some path conversion, to include CPATH and others. Usage of thos two
helpers is the same as of cl.exe and link.exe.
=20
Have fun with the new release, Markus

Re: [wgcc-dev] [gentoo-osx] PREFIX on Cygwin

[Michael H. <mic...@sa...>]

Hi,

I'm wondering that cygwin has fixed the hyperthreading-related bug[1],
only occurring on Windows >= XP, not until Win2000.
Well, there are some more recent posts on the list with some patches to
the cygwin-dll, but did not really find it fixed.

Well, facing this problem, and some others which seems that M$
implements things to prevent cygwin working on newer Windows-versions,
we have switched to Interix now - planning to use portage on Interix,
with wgcc[2] as 'cross-compiler' to produce native win32 executables.

[1] http://www.cygwin.com/ml/cygwin/2004-10/msg00610.html
[2] http://sourceforge.net/projects/interix-wgcc

-- haubi

On Tue, 2006-06-13 at 20:20 +0200, Grobian wrote:
> Hi!
> 
> Interesting to see some works along the windows way.  We never tried
> anything alike, but of course we would be very happy if it would work
> somehow in the end.
> 
> Could you give any error messages you get?  Maybe they look familiar or
> does somebody here know what they mean exactly.
> 
> Regards
> 
> 
> On 13-06-2006 11:08:56 -0700, Nimish Pachapurkar wrote:
> > Hello All,
> > 
> > I was trying to get PREFIX portage to work on Cygwin on Windows (XP). I am 
> > facing some issues in the process. Has anyone tried this before with Prefix 
> > Portage? I found that there is a project specifically for this purpose at 
> > http://gentoocygwin.sourceforge.net but that does not seem to support Prefix 
> > version of portage.
> > 
> > Any pointers in this regard would be appreciated.
> > 
> > Specifically today, I am facing a problem while emerging anything. I get an 
> > error saying that I am trying to emerge a package with a syntax error or 
> > corrupt ebuild file (which is definitely not the case). Also, emerge refuses to 
> > proceed with any dependency analysis whatsoever.
> > 
> > Thanks,
> > Nimish
> 
> -- 
> Fabian Groffen
> Gentoo for Mac OS X Project
-- 
Michael Haubenwallner                    SALOMON Automation GmbH
Forschung & Entwicklung                  A-8114 Friesach bei Graz
mailto:mic...@sa...  http://www.salomon.at
No HTML/MIME please, see http://expita.com/nomime.html