Hi,
I was also having the same problem. Then I figured that the SourceForge site
wasn't using any mirror at all for the GCC-G++ file download. So I changed
their URL to included the 'nchc' mirror and then placed it inside my
download manager and voila! it worked :-)
So, when downloading the file manually, you would be getting a download link
similar to this:
http://.dl.sourceforge.net/sourceforge/mingw/gcc-g++-3.4.5-20060117-3.tar.gz
change the above to the following by adding the 'nchc' to the beginning of
the link and it will download! ;)
http://nchc.dl.sourceforge.net/sourceforge/mingw/gcc-g++-3.4.5-20060117-3.tar.gz
Once downloaded, place it in the same folder where the Automated Installer
has downloaded the rest of the files, and run the installer again, it will
go swift this time ;) and you will have MingW installed nicely and
correctly.
Cheers,
Kamran
Chris Müller wrote:
>
> Hi everybody,
>
> i have a simple problem with the installation of the mingw-compiler and
> i hope i'm right here to ask you about this.
>
> yesterday i tried to install the compiler via the automated
> mingw-Installer. But it seems it haves some problems. The
> installer always fails with the message:
>
> ----
> Downloading mingwrt-3.15.1-mingw32.tar.gz
> Downloading w32api-3.12-mingw32-dev.tar.gz
> Downloading binutils-2.17.50-20060824-1.tar.gz
> Downloading gcc-core-3.4.5-20060117-3.tar.gz
> Downloading gcc-g++-3.4.5-20060117-3.tar.gz
> Create folder: C:\Entwicklungsumgebungen\mingw5.1
> Extract: C:\Entwicklungsumgebungen\mingw5.1\installed.ini... 100%
> Extracting mingwrt-3.15.1-mingw32.tar.gz
> Unable to create directory C:
>
> untgz::extract -d 'C:\Entwicklungsumgebungen\mingw5.1' -z
> 'D:\Downloads\mingwrt-3.15.1-mingw32.tar.gz'
> Writing bin/mingwm10.dll
> ....
> Writing lib/libmsvcr80.a
> gzread: incomplete block read
> Error: Failure reading from tarball.
> ----
>
> After trying to install it manually, i find out that the links to the
> gcc-g++ tarball on sourceforge.net seems to be dead
> (both in gcc4.3 and gcc3.4).
>
> Are there any other sources except sourceforge, where i can achieve this
> tarball?
>
>
> Gruß / Best Regards
> Chris
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
> CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>
> _______________________________________________
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.
>
> Most annoying abuses are:
> 1) Top posting
> 2) HTML/MIME encoded mail
> 3) Improper quoting
> 4) Improper trimming
>
>
--
View this message in context: http://www.nabble.com/Installation-MinGW-%2B-g%2B%2B-tp22104112p22139338.html
Sent from the MinGW - User mailing list archive at Nabble.com.

I want to know if a file is hidden or not.
I know stat() and the structure.
For example I check if a file is write protected this way:
(strucStat.st_mode & _S_IWRITE)
I know stat.h where _S_IWRITE is defined to. But I am not sure if there
is a macro for "hidden", too. Maybe something like _S_IHIDDEN ?
--
publictimestamp.org/ptb/PTB-5502 ripemd128 2009-02-21 18:00:04
85399BF130A050EEBCE9B4269BE9C0F2

[...thread hi-jacking message snipped...]
Just what has this to do with the message to which you replied? That
had a subject line: "autoconf for msys".
Since this is completely unrelated to the topic of the thread, I've
deleted it unread.
PLEASE DO NOT HI-JACK THREADS! When you want to raise a new topic,
then DO NOT REPLY to an existing thread -- start a new one.
--
Keith.

From: Greg Chicares <gchicares@...> - 2009-02-20 17:17
On 2009-02-20 15:34Z, Jesse Perla wrote:
>
> 1) Isn't the .a library file generated by the mingw compiler incompatible
> for linking into an Intel C++ project?
> For a C library, it should be possible.
I need to build a C++ library called Trilinos and some C++ projects
from COIN-OR, so sadly that won't work for me.
> If the makefiles follow normal conventions, specify
> CC=x:/path/to/whatever-C-compiler
> CXX=x:/path/to/whatever-C++-compiler
> ...also linker etc.
> CC=x:/path/to/my-wrapper-for-whatever-C-compiler
It sounds like my best bet is to tell the makefiles to use intel and
mess with the compiler/linker flags. Does anyone know of an existing
compiler/linker wrapper shell script I can scam/adapt? I am not
especially good at writing these kinds of things. Are there any other
"gotchas" if I go this approach?
Thanks for your help everyone.
Jesse

Hi,
I have installed on a Windows XP SP3, latest stable version of mingw/msys
as described
here : http://www.mingw.org/wiki/msys.
When I try to compile a source package, for instance gmp (Gnu MP Bignum
Library)
I get a popup message as shown on the following screenshot :
http://www.smartmobili.com/Downloads/mingw-gmp.PNG
Even if the message is in french you should be able to understand it ;-)
Subsystem MS-DOS 16 bits
rxvt00000f1c
Processor NTVDM has encoutered an unauthorized instruction
....
If I click on ignore, configure continue and seems to work.
I also have a question about this sentence :
"It is better to not install it in the same directory than MSYS, though
there should be no problem since MSYS 1.0.11."
Maybe you should clarify, either it works or it doesn't, should is not part
of my vocabulary.
If people could comment and report issues or not it would help to clarify
things.
Personally I have installed in the same folder so now I couldn't say if my
issue is due to this
possibility or not.
One last thing, I have noticed that your are mapping /usr to the root
folder where msys
is installed, could it be possible to create a real /usr folder for people
used to unx filesystem ?
Thanks

----- Original Message -----
From: "Keith Marshall" <keithmarshall@...>
>> Might be an issue. I see via google that 1.4.5 is required and
>> 1.4.11 is recommended.
>
> 1.4 is certainly too old, for *current* autoconf. You should install
> the 1.4.7 upgrade from the MSYS package set; (don't attempt to build
> anything later, as a MinGW application -- that will not work).
Yep - I've now installed 1.4.7
>
> You should also make sure you are using the MSYS build of perl; I
> notice you seem to have some other perl installed in your PATH, which
> IIRC is likely to be problematic.
Aaah, yes. The "other" perl, which was built from source in the cmd.exe
shell using MinGW, won't understand those nix style paths correctly. (I
didn't realize perl was even needed.)
So I've installed the msys build of perl-5.6.1 (and the crypt package which
is also needed), and removed the /perl entry from etc/fstab.
Once all of that has been done, autoconf-2.61 functions beautifully :-)
Thanks again, guys.
Cheers,
Rob

On Fri, Feb 13, 2009 at 4:15 PM, Keith Marshall
<keithmarshall@...> wrote:
> Quoting "Richard W.M. Jones" <rjones@...>:
>> > Secondly, our use of the name
>> > "MinGW" is unfortunate for us: Originally we were just going to
>> > recompile the MinGW packages from Debian (basically just the
>> > compiler/binutils/ w32api & runtime),
>
> Are you aware of the cross-compiler tool chain we ourselves promote?
> https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=12644
>
> Our objective in promoting this is to provide a platform neutral
> mechanism of setting up the cross-compiler tool chain; (I myself use
> it on Ubuntu and SUSE -- sorry, but Fedora didn't appeal to me, when
> I tried Fedora-9).
That is a nice solution which is good for some audience, but to many
others having stuff packaged and maintained by the distribution itself
is invaluable.
Additionally, the Fedora effort goes well beyond the cross tool chain,
so I'm not really sure how the two approaches could coexist.
> A properly named cross tool
> chain should simply use `mingw32', as the target identifier.
so Fedora is doing fine here :)
> Aside from the potential confusion for end
> users, (which of the many disparate project communities is best
> placed to offer authoritative advice and support?), this could so
> easily become yet another lost opportunity for co-operation and
> collaboration toward a common goal.
Of course, we need to educate users about where issues should be
reported first. For Fedora packages this is usually
bugzilla.redhat.com and the fedora-mingw mailing list. I will keep an
eye here to make sure users of the Fedora cross-toolchain report
problems in the proper channels.
>
>> I wish you well in you endeavor.
>
> As do I, (although I will spell it `endeavour'). :-) However, I
> would like to go further; your project is sure to share much common
> ground with our own. Let us establish channels of communication,
> such that both projects may progress in a spirit of co-operation and
> collaboration, to the greater common good of the broader integrated
> community served by both.
I am subscribed to both lists, but not really sure what exactly could
be done to let both communities leverage each other work.
If you have specific requests, feel free to ask :)
--
Gianluca Sforna
http://morefedora.blogspot.comhttp://www.linkedin.com/in/gianlucasforna

Hi JonY,
> make sure you are using the same compiler to compile and link libFLAC++.
>
Yup, I re-checked out just to be safe after downgrading gcc to 3.4.
>
> You should also make sure you link to the correct "libstdc++.a". You
> might want to search your /mingw/lib and any sub-directories for any
> duplicates just in case.
It looks like that was it. I did a find for libstdc++ under /mingw/lib and
got this:
./gcc/mingw32/4.3.0/libstdc++.a
./gcc/mingw32/4.3.0/libstdc++.la
./gcc/mingw32/4.3.0/libstdc++_s.a
./libstdc++.a
./libstdc++.la
I took a hopefully educated guess and tried moving the ones not in the gcc
directory, compiled the library just great! Thanks again for pointing me in
the right direction, that had me a bit baffled :)
- Chris

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

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