List Info

Thread: Wgcc 2.0.2 released.




Wgcc 2.0.2 released.
user name
2006-10-03 07:21:46
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:SFUwgcc).

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=158081&a
mp;atid=806404, or ask your
questions at the forums at
http:/
/sourceforge.net/forum/?group_id=158081.

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

Documentation can be found here:
http://sourceforge.net/project/showf
iles.php?group_id=158081&package_id=
203917&release_id=446943
Source Packages can be found here:
http://sourceforge.net/project/showf
iles.php?group_id=158081&package_id=
177049&release_id=445894
The Patch for Libtool can be found here:
http://sourceforge.net/project/showf
iles.php?group_id=158081&package_id=
196163&release_id=446510


_______________________________________________
http://
lists.gnu.org/mailman/listinfo/libtool
Monitor sync'ing under auto-boot? on OF 3?
user name
2006-10-03 03:59:15
Okay, so I am both behind the times and out of the loop,
BUT!

My long-reliable (pushing 12 years, if not pulling it)
7200/90 with
a 7500 motherboard replacement with a G3 processor finally
kicked
the bucket recently, and I'm finally getting around to
replacing it
in kind (rather than having the FreeBSD+2x3ware 9x00 storage
system
stand in... let's not get into an argument over that, the
vendor
supports the drivers and management interface there, and
they work
quite nicely).

Despite something of a version jump (I'm ashamed to admit it
was
still running... 1.6K. No, really), things under both NetBSD
and
OpenFirmware (almost as useful as OpenBoot!) 3 are mostly
familiar,
and OF 3 is mostly less of a pain than OF 1.0.5, only but if
the
system is permitted auto-boot? true (with output ostensibly
going
to the monitor, of course, not ttya), instead of boot
messages and
console, it is simply blank white. If, instead, boot is
issued
manually at the OF prompt, what I expect to happen does
(ofwboot.xcf
flies by, boot messages in the silly OpenFirmware font start
scrolling).

Setting boot-command to catch 5000 ms boot (or similar)
definitely
pauses as desired, syncs the monitor as normal, and, as
before,
displays blank white. (Hey, it was worth a shot.)

I realize, as I type, that I'm using a slightly abnormal
(21", Sony,
dual-input, etc) CRT, and it may behoove me to plug in a
less fruity
monitor and see if the problem persists, especially since
poking
at Google doesn't turn up anyone else with a similar
complaint.

But am I missing something obvious?

(The system in question is one of these:

http://support.apple.com/specs/powermac/P
ower_Mac_G4_Digital_Audio.html

The 533 MHz model with a(n?) NVIDIA GeForce2 MX. As
described there,
except the Intel EE Pro and D-Link DFE 530TX+ PCI cards.)

(In other news... how -current do I need to be for i2s to
actually
get configured? Is it as simple as its being excluded from
GENERIC?
Some mailing list history reading suggests that the driver
is
non-functional on some iBooks... but it's not clear that
this
implies that it mostly works. If audio can work, I'll be
getting
another of these systems--$250 at cherokeedata.com, whose
selection
I do recommend perusing--to run the stereo.)

-- 
gabriel rosenkoetter
greclipsed.net
[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )