 146
serge fukanchik wrote:
> So is there single file installer for mingw? I can't find it. If there is no such installer - how can i install mingw?
>
There is not. You also, however, have the option of manually extracting
the appropriate tarballs by hand, which is how I *always* create a new
installation. You'll need at minimum gcc-core, binutils, w32api, and
mingw-runtime. Further instructions should be available on the MinGW wiki.
I also distribute a set of more recent GCC binaries (which are neither
affiliated with nor supported by the MinGW project), with an all-in-one
installer that includes all the necessary packages. See
<> if you're interested.
-John E. / TDM
[Please break lines at a reasonable length like 72 characters.
That makes it easier to quote your question in a reply. Thanks.]
On 2009-05-31 21:28Z, serge fukanchik wrote:
>
> So is there single file installer for mingw? I can't find it.
> If there is no such installer - how can i install mingw?
AFAICT, this is the last monolithic installer:
It can be hard to find old files like that on sourceforge,
but some mirrors like ntua.gr list them plainly.
That file is old. I'd guess that it installs gcc-3.2.x,
but gcc-3.4.5 is the current stable version. If you want
the latest stable release, and the newer install program
doesn't work for you, then you need to download these files:
binutils-2.19.1-mingw32-bin.tar.gz
gcc-core-3.4.5-20060117-3.tar.gz
gcc-g++-3.4.5-20060117-3.tar.gz
mingwrt-3.15.2-mingw32-dev.tar.gz
w32api-3.13-mingw32-dev.tar.gz
and extract them all into one directory with gzip and tar.
(That's the complete set for C and C++; for other programming
languages, you'll need additional 'gcc-' files.)
Sorry for my frustration tone in this first post to this mailing list.
Many years ago i switched from cygwin to mingw because cygwin has network installer but mingw has single-file windows installer which didn't require network connection for installation. I could download one file and be sure that it is everything i need. I could write it to CD and use everywhere. There are number of problems with network installer: it requires network connection, it is slower to download many files than single one, if network connection is interrupted it starts from beginning, you need to handle many files instead of one and so on and so on.
And today i needed mingw again but couldn't find single file installer. Only networked one. Circle closed here. And of course it fails and can't finish installation. The message is:
Installation Aborted
The installation was not completed successfully.
...
gzread: incomplete block read
Error: Failure reading from tarball.
I tried several methods: download &install, download and then download&install, Previous, Current and Candidate. I tried full, minimal and custom installation but always get this result. Files which it tries to gunzip are correct and can be unpacked by other utilities without any errors or warnings.
So is there single file installer for mingw? I can't find it. If there is no such installer - how can i install mingw?
--- On Sun, 5/31/09, Peter <one2001boy@...> wrote:
> From: Peter <one2001boy@...>
> Subject: Re: [Mingw-users] MSYS 1.0.11 Release Candidate 1
> To: "MinGW Users List" <mingw-users@...>
> Date: Sunday, May 31, 2009, 9:08 AM
>
>
>
> ---
Tried to set INFOPATH, it doesn't work.
Also, used the option
info --directory c:\junk\info\ sed
failed with the same error:
info: dir: No such file or directory
C:\junk\info>dir sed*
Volume in drive C has no label.
Volume Serial Number is 34E4-DDED
Directory of C:\junk\info
01/09/2007 11:50 AM 15,903 sed.info-1.gz
01/09/2007 11:50 AM 11,592 sed.info-2.gz
01/09/2007 11:50 AM 1,125 sed.info.gz
3 File(s) 28,620 bytes
Peter
> also, there is no man.exe, not sure where to download?
>
> Thanks.
>
> Peter
>
>
>
>
> ------------------------------------------------------------------------------
>.
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
>:
>
>
--- On Sat, 5/30/09, asm23 <asmwarrior@...> wrote:
> Hi, You can take for a try.
>
>
I downloaded binutils-2.19.1-mingw32-bin.tar.gz from its website and not sure why there is no man.exe?
thanks.
Peter
Hi, all.
I work with GCC quit some time. Although I have been succeeded writing
makefiles, and compiling my work for Windows and BREW I have some doubt about
the creation and use of pre-compiled header.
Almost all my work must to be portable in the since that applications must run
on several versions of Windows (including Windows CE and Mobile) the same way.
For this set I use the Microsoft compiler and their creation/use of
pre-compiled headers are easily understood. But I am not sure if the versions
for BREW, that uses the gcc-arm-elf port, are right. This set also has to work
in the simulator and in the device the same way (obviously) but the compilation
time is taken to long when compared with the Microsoft compiler.
I am aware that GCC has more compliance with ANSI C and C89 that Microsoft
compiler. I also know that the compile time of GCC is a little bit greater
than the other one. I, really, just want to know if my creation/use of
pre-compiled headers in this matter is right.
The command line that I use to create the pre-compiled header is (extracted
from one of the makefiles I built):
OPTIONS = -fno-builtin -fno-operator-names -fno-rtti -mthreads -c
WARNINGS = -Wnon-virtual-dtor -Wimplicit -Wmissing-braces -Wparentheses \
-Wunused-variable -Wunknown-pragmas -Wshadow -Wsign-compare \
-Wno-multichar
# These DEFINES are for a Win32 build.
DEFINES = -D_WIN32_WINNT=0x0410 -DWINVER=0x0410 -D_WIN32_IE=0x0401 -DWIN32
-D_MBCS -D_USRDLL
# The pre-compiled header is created with this command:
gcc $(OPTIONS) -x -c++-header $(WARNINGS) $(DEFINES) $(INCLUDE) "src/file.cpp" \
-o "out/file.h.gch"
# Then I use this command line to use the pre-compiled header when compiling
# the other object files.
gcc $(OPTIONS) $(WARNINGS) $(DEFINES) -I"out" $(INCLUDE) "srs/other.cpp" \
-o "out/other.o"
The set of warnings has not to do with the creation/use of pre-compiled
headers. It is here just for completeness of way I use the compiler. Also,
the header file used to include the common header files is named "file.h" and
is included in every source (.cpp) of the application.
Am I doing this right?
Thanks,
Alessandro Antonello
After my problem with stl and tdm gcc, i decided to go back to the one
packaged with Code Blocks. I wanted to include in my project a wrapper
for Bullet named Ogrebullet. I compiled bot Ogrebullet components:
OgreBulletDynamics and OgreBulletCollisions successfully using the
provided Code Blocks project files, but when I link the generated libs
to my project i get an error saying that the file has an invalid format.
If the library file is generated without errors, what could be causing
the invalid format error?
--
Roger D. Vargas
Gentoo Linux 2008.0, The news for game programming newbies
______________________________________________
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
---
also, there is no man.exe, not sure where to download?
Thanks.
Peter
On 2009-05-30 22:30Z, Roger Durañona Vargas wrote:
> i installed tdm gcc 4.4 and found a weird problem.
That's a separate project not affiliated with MinGW.
Its website gives instructions for reporting problems:
i installed tdm
It's probably best to look at, and take inspiration from, how people
already do cross-compilation of lots of stuff from Linux to Windows.
The project I am familiar with is hosted by the openSUSE Build
Service. RPM-packaged sources (including patches where necessary) and
x86 and x64 Windows binaries (so far, packaged as "noarch" packages
from RPM's point of view) are here:
. You will want to unpack the source rpms and have a look at the spec
files. Some experience with the general idea of RPM is obviously
useful to understand what is going on.
There are also similar cross-compilation packages (with a slightly
longer history) in the Fedora repositories. I don't know if anybody
has been doing similar stuff in a Debian- (Ubuntu-) oriented way.
> 3) By chance, is there a way to deal with paths embedded
> in programs other than changing them manually?
In general, software built for Windows should not use any hard-coded
embedded paths at all. Instead, software should be freely installable
in whatever location the end-user chooses, and it should at run-time
detect where it is installed and construct any pathnames needed at
run-time from that. Ideally, it should work even if the installation
location contains arbitrary Unicode characters including such that
aren't present in the system codepage of the system.
> 4) Where is the best location for --prefix?
If the software is location-independent as I described above, whatever
--prefix you pass to a configure script is just a "dummy" one anyway.
In the stuff I build and distribute[1], I use for each package as
prefix a unique temporary directory (pathname based on the MD5 hash of
the package name and full version), and it is used only for the "make
install" phase. The files I then package for distribution for some
software package are collected from such a temporary package- and
version-specific location, but there is no expectation that these
paths exist on the end-user systems. (The use of a MD5 checksum as
part of the prefix is partly to make it more obvious that it is a
"dummy" path not expected to be present on the end-user machine.)
True, the prefix does often end up in strings in binaries (or even
configuration files), that's usually unavoidable, but that doesn't
mean that such pathnames would actually be used at run-time in
software that is properly post-installation relocatable. Much of the
software that I have ported to Windows works so that if it notices
that a configuration file contains a pathname that starts with the
configure-time prefix, it automagically replaces that prefix with the
run-time one.
(Yeah, there is a risk here that people who have a look in such
configuration files think that it is a problem that they contain
pathnames that obviously don't exist on their machines, and tediously
(and unnecessarily) then starts editing these configuration files.)
>.
In the case of the .pc files that pkg-config reads, when built for
Windows, pkg-config ignores the "prefix" value read from the .pc file
and instead deduces the prefix of a package based on the actual
location of its .pc file.
[1] I.e., the GTK+ and GNOME (as applicable) stack for Windows (32-
and 64-bit) available from. So far still a separate
effort from the openSUSE cross-build project, but eventually I will
stop doing my own builds and let the openSUSE cross-build project
"take over".
--tml
Hello All,
I am building Windows programs on Ubuntu Jaunty 9.04. It's working, but I have a few issues.
1) gettext wouldn't configure. It failed with a message
about not being able to execute tests in cross-compile
mode. I got around this by installing Wine.
If you were cross-compiling
on a system for which a Windows emulator does not exist,
how would you bypass this problem?
2) Having installed Wine, configure scripts no longer
detect that I am cross-compiling. Apparently, configure
detects cross-compilation by failure to execute a program
generated by the compiler. Now that Wine is installed,
they don't fail anymore.
Everything seems to build OK. Does it matter when
configure says 'Checking for cross-compilation ... no'?
3) By chance, is there a way to deal with paths embedded
in programs other than changing them manually?
4) Where is the best location for --prefix? I am thinking in
particular of cross-compiled binaries that are commonly
executed configure scripts, such as iconv, msgfmt,
pkg-config, etc. These may contain
hard-coded DOS-style paths. Would it be best to set my
prefix to something like c:/msys/1.0/local so that they will
work on my real machine (I'm running Linux in a virtual
machine) and install to Wine's drive C:?
Regards,
Alias John Brown.
_________________________________________________________________
Windows Live™: Keep your life in sync.
----- Original Message -----
From: Anthony Arnold
To: mingw-users@...
Sent: Tuesday, May 26, 2009 6:24 PM
Subject: [Mingw-users] Strange compilation error...
<snip>
<quote>*)'
</quote>
The callback start function for _beginthreadex is
unsigned long _beginthreadex (void *, unsigned, unsigned (__stdcall *)
(void *),
void*, unsigned, unsigned*);
G++'s error reporting could be better, but what is missing in your code is
the '__stdcall' attribute
Danny
I'm using midl.exe out of the windows SDK to produce an h file for the purpose of accessing a COM server. To make sure my environment is set up correctly, I've tried compiling this program with the h file included:
#include "foo.h"
int main(int argc, char *argv[]) {
return 0;
}
And I get this response:
$ gcc comclient.c
In file included from comclient.c:1:
foo.h:340: error: syntax error before "__RPC__deref_out"
foo.h:415: error: syntax error before "__RPC__deref_out"
foo.h:522: error: syntax error before "__RPC__deref_out"
foo.h:629: error: syntax error before "__RPC__deref_out"
foo.h:736: error: syntax error before "__RPC__deref_out"
foo.h:843: error: syntax error before "__RPC__deref_out"
foo.h:950: error: syntax error before "__RPC__deref_out"
foo.h:1057: error: syntax error before "__RPC__deref_out"
foo.h:1164: error: syntax error before "__RPC__deref_out"
foo.h:1282: error: syntax error before "__RPC__deref_out"
foo.h:1516: error: syntax error before "__RPC__deref_out"
foo.h:1825: error: syntax error before "__RPC__deref_out"
foo.h:2097: error: syntax error before "__RPC__deref_out"
foo.h:2559: error: syntax error before "__RPC__deref_out"
foo.h:2916: error: syntax error before "__RPC__deref_out"
foo.h:3023: error: syntax error before "__RPC__deref_out"
foo.h:3130: error: syntax error before "__RPC__deref_out"
I am invoking MIDL this way:
"C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin\midl.exe" /cpp_cmd gcc cpp_opt "-E -x c -U__stdcall -U_stdcall -U__GNUC__ -U__declspec -__inline__= -D__NO_CTYPE_INLINES -DMIDL_PASS -DWIN32_LEAN_AND_MEAN -IC:\MinGW\include" -I"C:\Program Files\Microsoft SDKs\Windows\v6.1\Include" -IC:\MinGW\include /header foo.h /tlb foo.h foo.idl
So my question is this : what is this __RPC__deref_out symbol, and where should it be defined? Is this the right place to ask this sort of question?
Woodrow Douglass
Software Design Engineer
Automatika, inc.
A QinetiQ North America Company
Technology Solutions Group
137 Delta Drive
Pittsburgh, PA 15238
(412) 968-1022 x34
wdouglass@...
**********************************************************************, forwarding, or copying of this communication is strictly prohibited. Whilst this message has been swept by anti-virus software, you are solely responsible for ensuring that any mail or attachments you receive are virus free. We disclaim liability for any damage you suffer as a consequence of receiving any virus; further communication will signify your consent to this. If you have received this communication in error, please notify info@... by e-mail or telephone, and delete the original message. Thank you.
**********************************************************************
Quoting "Page, Andy (UK)" <Andy.Page3@...>:
>
> Out of interest i have been using MSYS( make etc ) to build using the
> VisualStudioCompilers as this means i have a unified build system across
> Unix and Windows, has anyone else tried this, is anyone interested in
> how to do it ??!!
>
I think this would be beneficial as a wiki page. Please create one.
--
Earnie
Quoting Cesar Strauss <cestrauss@...>:
>.
>
W00t! Thanks Cesar, it has been a long time in development.
--
Earnie
Hi there. I've just written an extremely simple cross-platform wrapper
for posix threads. I compiled it on unix and it compiles with no
errors. The windows side with MinGW... not so pretty.); }#elseTHREAD_T InitiateDetachedThread(void* (*start)(void*), void* a) { THREAD_T t; pthread_create(&t, NULL, start, a); pthread_detach(t); return t;}#endif /*_WIN32*/ ."
_________________________________________________________________
View photos of singles in your area Click Here
Quoting Bismita Kumari Padhy <bismitapadhi@...>:
> Hi,
> I am trying to run mingw32-make for building Qt 4.3.1.But I am
> getting error that:
> C:\Qt\4.3.1>mingw32-make
> cd src\winmain\ && mingw32-make -f Makefile
> mingw32-make[1]: Entering directory `C:/Qt/4.3.1/src/winmain'
> mingw32-make -f Makefile.Debug
> mingw32-make[2]: Entering directory `C:/Qt/4.3.1/src/winmain'
> Makefile.Debug:116: *** multiple target patterns. Stop.
> mingw32-make[2]: Leaving directory `C:/Qt/4.3.1/src/winmain'
> mingw32-make[1]: *** [debug] Error 2
> mingw32-make[1]: Leaving directory `C:/Qt/4.3.1/src/winmain'
> mingw32-make: *** [sub-winmain-make_default-ordered] Error 2
>
> Do you have any idea to resolve this error.
>
> Thanks & Regards
>
> Bismita Padhi
>
>
Bismita,
I have redirected your email the appropriate list address. Please use
mingw-users@... to ask your questions. Also, please
use a proper subject for your mail and do not hijack another email
with a different question.
--
Earnie
I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details