- do the ar as nm and other tools need to be specified in a configuration?
- how to include gcc/mingw options when needed for python setup.py situations
I have noticed an extensive framework of source paths beyond the default
observed via gcc -v and wonder how these would be tied in when needed
to include all needed library paths
- do the ar as nm and other tools need to be specified in a configuration?
These are very generic questions, not related to Cygwin per se.
Grab first available book on GCC and read the answers from there.
- how to include gcc/mingw options when needed for python
- how to include gcc/mingw options when needed for python setup.py
situations
The Cygwin-hosted MinGW compilers are set up in a very similar way to cross-
compilation from Linux. Python and most of its infrastructure for building
C extensions do not support MinGW very well, from any host
I finally decided to go for the gusto and upgrade my Cygwin 1.5 to 1.7
and of course read the gcc-mingw announcement after the full upgrade.
I followed the instructions as shown here:
If you are reading this announcement AFTER having messed up your cygwin
installation, because you didn't
On 6/30/2011 10:40 AM, Brian Keener wrote:
The /usr/i686-pc-mingw32 directory structure on my machine is different
than documented above. Within /usr/i686-pc-mingw32 I have:
bin
lib
sys-root
and within sys-root I have
mingw
within mingw I find
bin
include
lib
share
This is
packages.
Thanks. 'Course, I'm going to have to slow-roll the actual compiler
given the wacky gcc-mingw-* issues (see
http://cygwin.com/ml/cygwin-announce/2011-04/msg00015.html )
but that horse has been beaten to death elsewhere.
--
Chuck
was made obsolete
in recognition of that, the major change is in the behavior of the
postinstall scripts of the various packages.
gcc-mingw-ada-20050522-3-src.tar.bz2
gcc-mingw-ada-20050522-3.tar.bz2
gcc-mingw-core-20050522-3-src.tar.bz2
gcc-mingw-core-20050522-3.tar.bz2
On 3/23/2011 12:22 PM, Charles Wilson wrote:
On 1/11/2011 3:16 PM, Charles Wilson wrote:
On 12/16/2010 12:01 PM, Charles Wilson wrote:
On 11/24/2010 12:41 AM, Charles Wilson wrote:
On 11/24/2010 12:06 AM, Christopher Faylor wrote:
Do you have the gcc package now?
If so, I'll download it
On Fri, Apr 29, 2011 at 08:55:41AM -0400, Charles Wilson wrote:
Can we get an ETA on that wrapper, or a go-ahead with its own dedicated
binutils for the mingw-cross toolchain, like all the other toolchains have?
Go ahead and release your packages.
cgf
On 1/11/2011 3:16 PM, Charles Wilson wrote:
On 12/16/2010 12:01 PM, Charles Wilson wrote:
On 11/24/2010 12:41 AM, Charles Wilson wrote:
On 11/24/2010 12:06 AM, Christopher Faylor wrote:
Do you have the gcc package now?
If so, I'll download it and attempt to
create a binutils wrapper to
On 1/24/2011 10:01 PM, Charles Wilson wrote:
On 1/24/2011 9:09 PM, Yaakov (Cygwin/X) wrote:
On Mon, 2011-01-24 at 11:54 -0500, Charles Wilson wrote:
Err...why?
exec_prefix=/usr/i686-pc-mingw32/sys-root/mingw
sharedlibdir=$(exec_prefix)/bin
pkg-config does not substitute $(parenthesis),
On 1/23/2011 11:36 PM, Yaakov (Cygwin/X) wrote:
On Tue, 2010-11-23 at 17:28 -0500, Charles Wilson wrote:
Updated packages are available by pointing setup.exe here:
http://cygutils.fruitbat.org/ITP/mingw-gcc/
Could you sign your setup.ini and post the GPG key (for setup -K)?
Err...not
On Mon, 2011-01-24 at 11:54 -0500, Charles Wilson wrote:
Err...why?
exec_prefix=/usr/i686-pc-mingw32/sys-root/mingw
sharedlibdir=$(exec_prefix)/bin
pkg-config does not substitute $(parenthesis), only ${curly_brackets}:
$ PKG_CONFIG_LIBDIR=/usr/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig \
On 1/24/2011 9:09 PM, Yaakov (Cygwin/X) wrote:
On Mon, 2011-01-24 at 11:54 -0500, Charles Wilson wrote:
Err...why?
exec_prefix=/usr/i686-pc-mingw32/sys-root/mingw
sharedlibdir=$(exec_prefix)/bin
pkg-config does not substitute $(parenthesis), only ${curly_brackets}:
D'oh. Thanks...
--
On Tue, 2010-11-23 at 17:28 -0500, Charles Wilson wrote:
Updated packages are available by pointing setup.exe here:
http://cygutils.fruitbat.org/ITP/mingw-gcc/
Could you sign your setup.ini and post the GPG key (for setup -K)?
= mingw-zlib-1.2.5-4-src.tar.bz2
=
).
Well, that's some good data; thanks. I'm just very VERY cautious when
it comes to something as core as a compiler toolchain...
If these updated gcc-mingw add-on packages were simply empty _obsolete
packages (with the cleanup postinstall script, as needed by the future
real mingw cross packages
On Tue, Jan 11, 2011 at 04:46:01PM -0600, Yaakov (Cygwin/X) wrote:
On Thu, 2010-12-16 at 12:01 -0500, Charles Wilson wrote:
cgf, any progress on creating a wrapper for mingw-binutils? If it's
turning out to be difficult, could we go ahead with a real
cross-configured mingw-binutils, and then
On Tue, Jan 11, 2011 at 07:12:03PM -0600, Yaakov (Cygwin/X) wrote:
Of course, by now binutils 2.21 and gcc-4.5.2 are out...
I need the features of binutils 2.21. Only the mingw binutils package
is at this revision level. How do I make mingw binutils work with Cygwin?
I'm trying to build a
On 12/16/2010 12:01 PM, Charles Wilson wrote:
On 11/24/2010 12:41 AM, Charles Wilson wrote:
On 11/24/2010 12:06 AM, Christopher Faylor wrote:
Do you have the gcc package now?
If so, I'll download it and attempt to
create a binutils wrapper to work with it. I'm really not keen on
having a
On Thu, 2010-12-16 at 12:01 -0500, Charles Wilson wrote:
cgf, any progress on creating a wrapper for mingw-binutils? If it's
turning out to be difficult, could we go ahead with a real
cross-configured mingw-binutils, and then maybe later update it with one
that installs simple wrapper .exe's
and just dump those outright? Aside
from nostalgia, what reason do we have to continue supporting gcc3 when
AFAIK no other major distro does so?
This would mean making these empty _obsolete packages (with cleanup
postinstall scripts if necessary), and dropping the gcc-mingw-* deps
from gcc-* (3.x
), and dropping the gcc-mingw-* deps
from gcc-* (3.x).
There are two reasons. First, if something goes belly up with the new
cross compiler (but not the headers and runtime libs) I want a fallback
for folks. And, rolling back is going to be difficult, given (again)
the weird directory/symlink
?
There are two reasons. First, if something goes belly up with the new
cross compiler (but not the headers and runtime libs) I want a fallback
for folks. And, rolling back is going to be difficult, given (again)
the weird directory/symlink manipulations that the existing
(rolled-back-to?) gcc-mingw
On 11/24/2010 12:41 AM, Charles Wilson wrote:
On 11/24/2010 12:06 AM, Christopher Faylor wrote:
Do you have the gcc package now?
If so, I'll download it and attempt to
create a binutils wrapper to work with it. I'm really not keen on
having a drawn out discussion about this. Maybe I'll
Hi Chuck,
On 23 November 2010 17:28, Charles Wilson wrote:
Chris Sutcliff: I don't intend to adopt your mingw-runtime package, but
I needed to provide a sys-root compatible version. I assume that once
the new cross compiler goes live you'll continue building
mingw-runtime packages, only now
setup and upgrade gcc-mingw-* if any are installed
on your system. Do NOT allow mingw-binutils to be installed.
Do NOT allow mingw-w32api or mingw-pthreads to be installed.
Do NOT upgrade mingw-runtime. Do NOT install the cross
compiler packages (mingw-gcc-*). Do NOT upgrade
On 11/23/2010 5:28 PM, Charles Wilson wrote:
The attached patch does this
automatically.
Yeah, about that...
--
Chuck
? .Tpo
? chuck-doconfigure
? chuck-doconfigure.patch
? doconfigure-old
? yaakov-doconfigure
? yaakov-doconfigure.patch
Index: bootstrap.sh
their gcc-mingw (and probably didn't even notice), so
they'll be fine.
Would it be possible to have a postinstall script for one of the new
packages that includes the awkward fixups? That way automatic fixup is
possible if you just reinstall the appropriate package, which seems
simple to support
the symlinks already exist (thanks to the OLD
gcc-mingw- packages), they can screw up unpacking the *new* files --
redirecting them from their intended location in the new scheme under
/usr/i686-pc-mingw32, and into the OLD location under /usr/lib/
So, somehow, you have to *remove* the symlinks
simple to support?
The problem is, because the symlinks already exist (thanks to the OLD
gcc-mingw- packages), they can screw up unpacking the *new* files --
redirecting them from their intended location in the new scheme under
/usr/i686-pc-mingw32, and into the OLD location under /usr/lib
On Tue, Nov 23, 2010 at 05:28:46PM -0500, Charles Wilson wrote:
DO NOT ALLOW setup.exe to install mingw-binutils yet, even though
setup.exe will whine about it. Nor mingw-w32api or mingw-runtime, or
any of the mingw libraries (zlib, bzip2, xz, libgpg-error, libgcrypt)
I'm not comfortable with
On 11/23/2010 7:41 PM, Christopher Faylor wrote:
On Tue, Nov 23, 2010 at 05:28:46PM -0500, Charles Wilson wrote:
DO NOT ALLOW setup.exe to install mingw-binutils yet, even though
setup.exe will whine about it. Nor mingw-w32api or mingw-runtime, or
any of the mingw libraries (zlib, bzip2, xz,
On Tue, Nov 23, 2010 at 10:36:26PM -0500, Charles Wilson wrote:
On 11/23/2010 7:41 PM, Christopher Faylor wrote:
On Tue, Nov 23, 2010 at 05:28:46PM -0500, Charles Wilson wrote:
DO NOT ALLOW setup.exe to install mingw-binutils yet, even though
setup.exe will whine about it. Nor mingw-w32api or
. Don't install ANY of them unless you first manually
remove the symlinks
/usr/i686-pc-mingw32/bin
/usr/i686-pc-mingw32/lib
/usr/i686-pc-mingw32/include
or Bad Things(tm) may happen.
The updated gcc-mingw-* gcc-3 addon packages' postinstall scripts are
supposed to handle this for you
On 11/23/2010 7:28 PM, Peter Rosin wrote:
Over in linux-land, the mingw compiler is usually named i586-..., is that
an option?
On Fedora and Mandriva, yes. It seems SuSe uses i686-pc-mingw32. I
think the target should match (as closely as is sane) the way
mingw.org's native compiler is
On 2006-10-18, Christopher Faylor [EMAIL PROTECTED] wrote:
On Wed, Oct 18, 2006 at 02:22:23AM +, Mike wrote:
Does someone have a bit of code that can be compiled static and mingw
(the way I understand it) to remove all cygwin dependencies that will
run as a windows (xp) service for starting
On Wed, Oct 18, 2006 at 11:41:51AM +, Mike wrote:
On 2006-10-18, Christopher Faylor [EMAIL PROTECTED] wrote:
On Wed, Oct 18, 2006 at 02:22:23AM +, Mike wrote:
Does someone have a bit of code that can be compiled static and mingw
(the way I understand it) to remove all cygwin dependencies
Does someone have a bit of code that can be compiled static
and mingw (the way I understand it) to remove all cygwin
dependencies that will run as a windows (xp) service for
starting vbscripts? I cannot install cygwin on all my
windows boxes and have a limit to how large an executable
I can
On Wed, Oct 18, 2006 at 02:22:23AM +, Mike wrote:
Does someone have a bit of code that can be compiled static and mingw
(the way I understand it) to remove all cygwin dependencies that will
run as a windows (xp) service for starting vbscripts? I cannot install
cygwin on all my windows boxes
for the standard tools.
However, it did not fix the problem for -mno-cygwin compile option
specifying to link with the mingw libraries, and the now old, mingw
specific, libstdc++.a. So, I need to upgrade my gcc-mingw-* packages to fix
the problem, however they have not been updated
Could someone please upload matching gcc-mingw-* packages that contain the
fix applied to 3.4.4-2?
Request duly noted. I'm half-way through updating the main cygwin gcc
release ATM; I'll look at this after I've got it done and before I move on to
thinking about 3.4.6.
Updated binary packages
I am attempting to install Cygwin and I want to install some of the GCC
compilers.
Apparently, all of the gcc compilers require their respective
gcc-mingw-* packages in order to work, so there is an enforced
dependency between these packages.
When I do the setup, it gets 98% of the way
Wes Gamble wrote:
I am attempting to install Cygwin and I want to install some of the GCC
compilers.
Apparently, all of the gcc compilers require their respective
gcc-mingw-* packages in order to work, so there is an enforced
dependency between these packages.
When I do the setup, it gets
On 13 May 2006 16:04, James McLaughlin wrote:
Hi,
A while ago I downloaded the source packages for the
Cygwin versions of gcc-mingw-core and gcc-mingw-g++.
However, after I decompressed them I found that they
didn't contain any source except a few header files,
but that they did contain
Dave Korn wrote:
[EMAIL PROTECTED] /usr/src ls -la gcc-mingw-core-20050522-1/
total 3521
drwxrwx---+ 2 dk Users 0 May 15 12:05 .
drwxrwx---+ 36 dk Users 0 May 15 12:06 ..
-rwxr-x---+ 1 dk Users3762 Jun 4 2005 Makefile.in
-rwxr-x---+ 1 dk Users 72828 Jun 4 2005
On 15 May 2006 12:27, Brian Dessent wrote:
Dave Korn wrote:
[EMAIL PROTECTED] /usr/src ls -la gcc-mingw-core-20050522-1/
total 3521
drwxrwx---+ 2 dk Users 0 May 15 12:05 .
drwxrwx---+ 36 dk Users 0 May 15 12:06 ..
-rwxr-x---+ 1 dk Users3762 Jun 4 2005 Makefile.in
!
Ok, guess I'll have to do something about that. Thanks for pointing it
out,
Brian. First things first, though: I'm only just getting on tops of how the
current packaging works.
Also note the strange way in which gcc-mingw-* binary packages work --
when unpacked by setup.exe only
Hi,
A while ago I downloaded the source packages for the
Cygwin versions of gcc-mingw-core and gcc-mingw-g++.
However, after I decompressed them I found that they
didn't contain any source except a few header files,
but that they did contain a few executables.
I posted this fact as part
Hallo Igor,
Am Montag, 30. August 2004 um 16:14 schriebst du:
On Mon, 30 Aug 2004, Gerrit P. Haase wrote:
This is in binutils/ld/configure.tgt:
i[3-7]86-*-cygwin*) targ_emul=i386pe ;
targ_extra_ofiles=deffilep.o pe-dll.o
test $targ !=
-Original Message-
From: cygwin-owner On Behalf Of Gerrit P. Haase
Sent: 03 September 2004 16:08
To: Igor Pechtchanski
Hallo Igor,
I'm not Igor! Heh, PMFBI!
On Mon, 30 Aug 2004, Gerrit P. Haase wrote:
This is in binutils/ld/configure.tgt:
i[3-7]86-*-cygwin*)
Igor Pechtchanski schrieb:
FWIW, I don't know what (if anything) has changed... I've used gcc
-mno-cygwin recently with no problems. What exactly needs to be done to
reproduce the problem?
Igor
for me this fails:
install efsprogs and compile a mingw project which uses -luuid
this
this installs /usr/lib/libuuid.a, which has nothing to do with
/usr/lib/w32api/libuuid.a and the library search path favours the
efsprogs lib of course. no mount problem.
Now we get the the bottom of the problem!
It's nothing to do with the gcc-mingw package at all. Instead, it is an
e2fsprogs
or something similar.
-Samrobb
-Original Message-
From: Max Bowsher [mailto:[EMAIL PROTECTED]
Sent: Tue 8/31/2004 7:09 AM
To: [EMAIL PROTECTED]
Cc:
Subject: Re: BUG gcc-mingw 20040810-1 library search path
Reini Urban
to do with the gcc-mingw package at all. Instead, it is an
e2fsprogs packaging problem.
Someone want to re-report in a new thread, with an appropriate subject?
e.g. e2fsprogs installs libuuid.a, hides w32api/libuuid.a
Reini's already done this: http://cygwin.com/ml/cygwin/2004-08/msg01251.html
the the bottom of the problem!
It's nothing to do with the gcc-mingw package at all. Instead, it is
an e2fsprogs packaging problem.
Someone want to re-report in a new thread, with an appropriate subject?
e.g. e2fsprogs installs libuuid.a, hides w32api/libuuid.a
Reini's already done this:
http
the
efsprogs lib of course. no mount problem.
Now we get the the bottom of the problem!
It's nothing to do with the gcc-mingw package at all. Instead, it is
an e2fsprogs packaging problem.
Someone want to re-report in a new thread, with an appropriate subject?
e.g. e2fsprogs installs
On Tue, Aug 31, 2004 at 02:08:22PM -0400, Igor Pechtchanski wrote:
Well, traditionally, you waited until the *third* iteration to step in,
and this is technically still in its second iteration... :-)
Ok. Please poke me if I seem to be drifting off.
cgf
--
Unsubscribe info:
Robb, Sam schrieb:
Already noted, Max. I'm aware of the problem, but don't have time to address it
immediately. I should be able to get to it soon, though. If you have any suggestions
as to where the libuuid from e2fsprogs should go, I'd be glad of the advice... IIRC,
Reini suggested
Gerrit P. Haase schrieb:
$ export tooldir=/usr/i686-pc-mingw32
$ ls -ld ${tooldir}/../lib/w32api
drwxrwxr-x+ 2 Administ SYSTEM 0 Jul 30 17:25
/usr/i686-pc-mingw32/../lib/w32api/
$
To the OP: your problem may potentially be that you're missing the
/usr/lib mount. However, since you
In previous versions of the mingw backend distributed
with Cygwin's gcc port, the frontend drivers would
append both /usr/include/lib/mingw *and*
/usr/lib/w32api to the linker's path. This happens no
more with the latter.
This has broken the configuration scripts of at least
two applications I'm
://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
This is what I was talking about before. gcc mingw does not built a
win32 binary for native.
The library
Hallo sengtsongpa-cygwin001,
Am Sonntag, 29. August 2004 um 17:20 schriebst du:
In previous versions of the mingw backend distributed
with Cygwin's gcc port, the frontend drivers would
append both /usr/include/lib/mingw *and*
/usr/lib/w32api to the linker's path. This happens no
more with
--- Gerrit P. Haase [EMAIL PROTECTED] escribió:
Hallo sengtsongpa-cygwin001,
Am Sonntag, 29. August 2004 um 17:20 schriebst du:
In previous versions of the mingw backend
distributed
with Cygwin's gcc port, the frontend drivers would
append both /usr/include/lib/mingw *and*
Hallo sengtsongpa-cygwin001,
1. Grab a copy of Cygwin Setup sources from CVS (the
stable source bundle idstributed with the net
installer will do equally well). You need a copy of
libgetopt++ from a parallel directory.
2. Bootstrap and configure:
bash-2.05b-$ ./configure CC=gcc
--- Gerrit P. Haase [EMAIL PROTECTED] escribió:
Hallo sengtsongpa-cygwin001,
Which version of gcc do you think it is working?
Have you reinstalled
the 'known to work' gcc version? Isn't linking done
by the linker?
Now, that was totally uncalled for; such cheap shots
are unbelievable
On Mon, 30 Aug 2004, Gerrit P. Haase wrote:
Hallo sengtsongpa-cygwin001,
[snip]
This is in binutils/ld/configure.tgt:
i[3-7]86-*-cygwin*) targ_emul=i386pe ;
targ_extra_ofiles=deffilep.o pe-dll.o
test $targ != $host
Hello Noname,
Maybe the definition of tooldir for binutlis builds
has changed?
You tell me.
Hey, I'm not the binutils maintainer, I maintain gcc.
At least, document it, make it *clearly visible* that
this is the new policy: *No implicit support for
w32api libraries*.
I didn't was
Hallo Igor,
Am Montag, 30. August 2004 um 04:23 schriebst du:
On Mon, 30 Aug 2004, Gerrit P. Haase wrote:
This is in binutils/ld/configure.tgt:
i[3-7]86-*-cygwin*) targ_emul=i386pe ;
targ_extra_ofiles=deffilep.o pe-dll.o
test $targ !=
is an upgrade helper, it
includes no files but pulls the `gcc-core' `gcc-g++' packages
automatically if selected via setup.exe chooser to simplify first-time
installations.
Driver packages available:
Ada gcc-ada / gcc-mingw-ada
Cgcc-core / gcc-mingw-core
C++ gcc-g
is an upgrade helper, it
includes no files but pulls the `gcc-core' `gcc-g++' packages
automatically if selected via setup.exe chooser to simplify first-time
installations.
Driver packages available:
Ada gcc-ada / gcc-mingw-ada
Cgcc-core / gcc-mingw-core
C++ gcc-g
hello
on the latest release it seems that there is a problem with gcc-mingw
in fact the src package and the package contains nothing
c616cffee0f344c37fd4e045a7a87054 gcc-mingw-20030911-4-src.tar.bz2
c616cffee0f344c37fd4e045a7a87054 gcc-mingw-20030911-4.tar.bz2
i'm using the ftp://ftp
On Jul 15 11:16, bertrand marquis wrote:
hello
on the latest release it seems that there is a problem with gcc-mingw
in fact the src package and the package contains nothing
c616cffee0f344c37fd4e045a7a87054 gcc-mingw-20030911-4-src.tar.bz2
c616cffee0f344c37fd4e045a7a87054 gcc
Hi,
I am looking for gcc2 2.95.3-10 for cygwin environment, running on Win2k.
Where can I download it from ?
Do you happen to know ?
I can not find it anywhere...
Thanks,
Oz
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
and did not find any problems (no multiple copies of
cygwin1.dll, sh.exe and so on). I'm not attaching this to my message `cause
the problem is solved already: after _rebooting_ I installed gcc-mingw
packages without any further problems (but I am sure that there was no
request to reboot from SETUP.EXE
and did not find any problems (no multiple copies of
cygwin1.dll, sh.exe and so on). I'm not attaching this to my message `cause
the problem is solved already: after _rebooting_ I installed gcc-mingw
packages without any further problems (but I am sure that there was no
request to reboot from SETUP.EXE
Hello,
The problem is, that suddenly I've found out that I couldn't use
-mno-cygwin option. I'm getting errors saying that there is no `cc1' and
so on. 'cygcheck -c' says that everything is Ok with gcc-mingw-* packages,
but when I looked inside .../gcc-lib/i86-pc-cygwin/ I did not find anything
On Wed, 25 Feb 2004, Alexei Lioubimov wrote:
Hello,
The problem is, that suddenly I've found out that I couldn't use
-mno-cygwin option. I'm getting errors saying that there is no `cc1' and
so on. 'cygcheck -c' says that everything is Ok with gcc-mingw-* packages,
but when I looked inside
Teun wrote:
As recorded in the thread gcc -mno-cygwin fails, there is I think
a packaging error in gcc-mingw-3.3.1-20030804-1.tar, component
of the gcc-mingw-3.3.1-20030911-2.tar.bz2 package.
Please upgrade to gcc-3.3.1-3.
Gerrit
--
=^..^= http
Gerrit schrieb:
oh my god, sorry, I was fooled by the sort order in my mailbox, forget
it;)
Teun wrote:
As recorded in the thread gcc -mno-cygwin fails, there is I think
a packaging error in gcc-mingw-3.3.1-20030804-1.tar, component
of the gcc-mingw-3.3.1-20030911-2.tar.bz2 package
I've made a new version of gcc available for download.
This release includes some changes in the package layout. There are
now several packages, one package including the core components and
one package for each additional front end.
Since the gcc-mingw package doesn't exist anymore
Hallo,
I would like to rename this package to mingw-gcc. Probably it would be
no bad idea to introduce a new category 'MinGW' similar to the 'XFree'
category for future additions.
Any comments?
Gerrit
--
=^..^=
On Wed, Oct 22, 2003 at 01:13:28PM +0200, Gerrit P. Haase wrote:
Hallo,
I would like to rename this package to mingw-gcc. Probably it would be
no bad idea to introduce a new category 'MinGW' similar to the 'XFree'
category for future additions.
Any comments?
It is not worth the aggravation.
Christopher schrieb:
On Wed, Oct 22, 2003 at 01:13:28PM +0200, Gerrit P. Haase wrote:
Hallo,
I would like to rename this package to mingw-gcc. Probably it would be
no bad idea to introduce a new category 'MinGW' similar to the 'XFree'
category for future additions.
Any comments?
It is not
to have a
gcc/{gjc,gcc,f77} and mingw/{gcc,gcj,f77} etc. or a
gcc/{mingw/{gcj,gcc,f77},gcc,f77} .
I don't really know. I think I'd have a mild personal preference for
seeing things sorted like:
gcc
gcc-mingw
gcj
gcj-mingw
over
gcc
gcj
gdb
.
.
.
mingw-gcc
mingw-gcj
but I wouldn't object if you
[EMAIL PROTECTED] wrote:
[SNIP]
See above. I think that's an it depends. If I was looking for gcc
and knew about mingw, I might expect to find a gcc-mingw package.
No argument here. But along the same lines, mingw-zib should probably
be changed to zlib-mingw.
Cheers,
Nicholas
On Wed, 22 Oct 2003, Christopher Faylor wrote:
[snip]
However, the question is if it provides more value to have a
gcc/{gjc,gcc,f77} and mingw/{gcc,gcj,f77} etc. or a
gcc/{mingw/{gcj,gcc,f77},gcc,f77} .
I don't really know. I think I'd have a mild personal preference for
seeing things
On Wed, Oct 22, 2003 at 12:52:38PM -0400, Nicholas Wourms wrote:
[EMAIL PROTECTED] wrote:
[SNIP]
See above. I think that's an it depends. If I was looking for gcc
and knew about mingw, I might expect to find a gcc-mingw package.
No argument here. But along the same lines, mingw-zib should
package name would make sense.
However, the question is if it provides more value to have a
gcc/{gjc,gcc,f77} and mingw/{gcc,gcj,f77} etc. or a
gcc/{mingw/{gcj,gcc,f77},gcc,f77} .
I don't really know. I think I'd have a mild personal preference for
seeing things sorted like:
gcc
gcc-mingw
On Wed, Oct 22, 2003 at 12:56:03PM -0400, Igor Pechtchanski wrote:
I agree with Chris here. IMO, gcc-mingw is a cross-compiler targeting the
mingw architecture. I have seen packages on Linux named gcc-arch,
so I think gcc-mingw is more appropriate (where gcc alone assumes
gcc-cygwin, or even
On Wed, Oct 22, 2003 at 10:00:43PM +0200, Corinna Vinschen wrote:
On Wed, Oct 22, 2003 at 12:56:03PM -0400, Igor Pechtchanski wrote:
I agree with Chris here. IMO, gcc-mingw is a cross-compiler targeting the
mingw architecture. I have seen packages on Linux named gcc-arch,
so I think gcc-mingw
I agree with Chris here. IMO, gcc-mingw is a cross-compiler targeting the
mingw architecture. I have seen packages on Linux named gcc-arch,
so I think gcc-mingw is more appropriate (where gcc alone assumes
gcc-cygwin, or even gcc-i686-pc-cygwin).
Well, when you build gcc, binutils, et al
On Wed, Oct 22, 2003 at 04:03:52PM -0400, Christopher Faylor wrote:
On Wed, Oct 22, 2003 at 10:00:43PM +0200, Corinna Vinschen wrote:
On Wed, Oct 22, 2003 at 12:56:03PM -0400, Igor Pechtchanski wrote:
I agree with Chris here. IMO, gcc-mingw is a cross-compiler targeting the
mingw
Hallo Nicholas,
Don't you mean i686-pc-mingw32-gcc?
Hmmm, I see. Ok, after thinking a while, another question came to my
mind. Currently, installing the gcc package pulls gcc-mingw via the
setup.hint requires: line, so if it is installed implicit, the name
isn't important at all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher Faylor wrote:
| I don't really know. I think I'd have a mild personal preference for
| seeing things sorted like:
|
| gcc gcc-mingw gcj gcj-mingw
FWIW i agree, people will already see all mingw packages in the MingW
new category (which
Hi all,
I recently ugrade to
gcc 3.3.1-2
gcc-mingw 20030911-3
But now got some problems linking MSVC compiled static libraries with the
gcc and the -mno-cygwin option
here is an example where MS.c/MS.h which contains a very simple function
(plus, see code
Hallo Jim,
you wrote:
I tried uncompressing, configuring, and make of gcc.
Recompiling and installing 3.3.1-1 fails to install the headers.
Subsequent uncompress, configure, recompile of 3.2-3 failed
to compiler.
Checking the gcc java list
http://gcc.gnu.org/ml/java/
doesn't reveal (to
Christopher Faylor wrote:
On Fri, Oct 03, 2003 at 07:07:54PM -0700, Jim Kleckner wrote:
Is it possible the java code simply wasn't configured to build?
All of the java headers are missing.
Christopher Faylor wrote:
I've moved all of the latest gcc stuff out of test and into current.
This is
Is it possible the java code simply wasn't configured to build?
All of the java headers are missing.
Christopher Faylor wrote:
I've moved all of the latest gcc stuff out of test and into current.
This is the standard gcc 3.3.1 release from gcc.gnu.org + patches from
Danny Smith and (to a vastly
Jim Kleckner wrote:
...
I tried uncompressing, configuring, and make of gcc.
Recompiling and installing 3.3.1-1 fails to install the headers.
Subsequent uncompress, configure, recompile of 3.2-3 failed
to compiler.
To be clear, the install ofo 3.3.1-1 succeeds but it doesn't appear
that the
On Fri, Oct 03, 2003 at 07:07:54PM -0700, Jim Kleckner wrote:
Is it possible the java code simply wasn't configured to build?
All of the java headers are missing.
Christopher Faylor wrote:
I've moved all of the latest gcc stuff out of test and into current.
This is the standard gcc 3.3.1 release
1 - 100 of 141 matches
Mail list logo
