mingw-users Mailing List for MinGW - Minimalist GNU for Windows

Do you really need to install msysDVLPR? My guess is that you don't. It is 
usually only necessary if you plan to help with the development of MSYS. If 
you don't need it then having an unnecessary extra set of tools will 
probably just cause confusion.

As for MinGW, it is certainly possible to install it after MSYS but you will 
need to edit /etc/fstab manually in that case.

Luke

----- Original Message ----- 
From: "Chauka Chauka" <ch...@gm...>
To: <min...@li...>
Sent: Monday, August 29, 2005 11:21 PM
Subject: [Mingw-users] Installation order (newbie)


Dear List,

I have tried my best to follow the instructions for installing first
MSYS (I'm  used to bash courtesy of Mac OS X) and then I want to soon
move on to MinGW. I ran the MSYS 1.0.11 exe installer (from snapshot)
and it works just fine (I'm installing on my XP Pro machine in
C:\tools\msys\1.0\  Next, I installed msysDTK (exe installer) version
1.0.1 ... no problems there that I'm aware of. Then, I install
msysDVLPR-1.0.0-alpha-1.tar.gz per the suggestions in the Wiki (I
followed the main installation, I do not follow the alternative
installation option) ... making sure to copy wincon.h as directed to
/usr/include, etc. (note: is /usr a symbolic link or something? I
can't find it when I cd to / and type "ls -al" but I can cd to /usr or
/usr/include

What I can't figure out exactly is what I should next install after
msysDVLPR? I tried the mingw runtime (being very careful to first run
msysdvlpr to get myself into a new shell which it then operate from
such that I'm in the MsysBuildEnvironment.

But here's where I get stumped -- I don't know what I try building and
installing next. I tried to configure, make and install the more
recent binutils (2.16.91 -- from Candidate) and even though configure
(with the options in the .sh works fine), make has a heart attack.
When I did so, I was very careful to follow the Wiki's suggestions
(e.g., create separate src and build directories and cook things in
the build directory as in configure ../src/.. ...)

Since that binutils didn't work, then tried to do the same for the
mingw-runtime-3.8 but again had problems with make (even with
configure, I wasn't sure what args to pass in so I kind of guessed by
looking at the args for binutils). Make didn' tlike the runtime 3.8
either.

I certainly don't yet have any of the mingw32-gcc, minggw32-g++, etc.
tools installed but does it make a difference? My preference is to
build everything from soruce if at all possible and using the .exe's
minimally (e.g., I had to use the exe installers for msys exe and
msysDTK exe). I really want to replace gcc that comes with msys (want
to use gcc candidate 3.4.x for example).

Any suggestions as to the order for building from source (after the
exes have been run) would be greatly appreciated. I have both /msys
and /mingw directories ready and rarin' to go. Did I miss something?

Thanks a ton for any suggestions.

Cheers,

-CK

Torsten Mohr wrote:

>I think that the problem is rather caused by some calls in gcc that
>are not available on MinGW.  I thought there might be a patch available
>to work around these calls or to remove them where possible?
>  
>
You need to patch so that fixinc is not built (for gcc prior to 4.0.0) 
there are some good instructions on the wiki -> 
http://www.mingw.org/MinGWiki/index.php/mingw%20hosted%20cross%20compiler 
(even if I do say so myself ;-) )

Dave

Hi,

> cross compiler from where to where, i.e. which is your host
> and what is target ?

sorry for leaving out these informations.  I use MinGW on
Windows 2000, i want to generate a cross compiler that
runs on Windows 2000 for an embedded controller, the
NEC V850E.

I successfully did this on a linux host and under cygwin.
Basically i always configured and compiled binutils for that
target.  On MinGW i did this by:

../binutils-2.16/configure --target=v850e-unknown-elf
make
make install

> Or in other words:
> You may want to give a few more details as to what you are
> trying to achieve and of course what your environment is etc.

For gcc i did:

../gcc-3.4.4/configure --target=v850e-unknown-elf --enable-languages="c"

> You are aware that you need a couple of system libs and headers
> from the target system to successfully create your cross compiler ?

Yes, i know that.  I plan to install newlib-1.13.0 after installing
gcc.

> The errormsgs you posted _could_ result from using the wrong
> set of headers but that's only a wild guess as I have no idea
> what you are actually doing.

I'd wonder, at that level i only want to build the gcc cross compiler
for V850E, i'll install the libs later.


I think that the problem is rather caused by some calls in gcc that
are not available on MinGW.  I thought there might be a patch available
to work around these calls or to remove them where possible?


Best regards,
Torsten.

> i try to compile gcc-3.4.4 as a cross compiler with MinGW.
>=20
> I successfully compiled and installed binutils as a cross
> tool chain.  I downloaded gcc-3.4.4 and also applied the
> patch gcc-3.4.4-20050522-1-src.diff.
>=20
> It fixed the previous problem with collect2.c, but now i
> get:

cross compiler from where to where, i.e. which is your host
and what is target ?

Or in other words:
You may want to give a few more details as to what you are
trying to achieve and of course what your environment is etc.

You are aware that you need a couple of system libs and headers
from the target system to successfully create your cross compiler ?

The errormsgs you posted _could_ result from using the wrong
set of headers but that's only a wild guess as I have no idea
what you are actually doing.

Best,
Michael
=2D-=20
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mg...@te...
 GPG-keys available on request or at public keyserver

Hi,

i try to compile gcc-3.4.4 as a cross compiler with MinGW.

I successfully compiled and installed binutils as a cross
tool chain.  I downloaded gcc-3.4.4 and also applied the
patch gcc-3.4.4-20050522-1-src.diff.

It fixed the previous problem with collect2.c, but now i
get:

In file included from ../../../gcc-3.4.4/gcc/fixinc/../../include/xregex.h:26,
                 from ../../../gcc-3.4.4/gcc/fixinc/fixlib.h:35,
                 from ../../../gcc-3.4.4/gcc/fixinc/fixincl.c:24:
../../../gcc-3.4.4/gcc/fixinc/../../include/xregex2.h:548: warning: ISO C90 
does not support `static' or type qualifiers in parameter array declarators
In file included from ../../../gcc-3.4.4/gcc/fixinc/fixincl.c:105:
../../../gcc-3.4.4/gcc/fixinc/fixincl.x:76: warning: string length `552' is 
greater than the length `509' ISO C89 compilers are required to support
../../../gcc-3.4.4/gcc/fixinc/fixincl.x:121: warning: string length `532' is 
greater than the length `509' ISO C89 compilers are required to support
../../../gcc-3.4.4/gcc/fixinc/fixincl.x:165: warning: string length `808' is 
greater than the length `509' ISO C89 compilers are required to support
../../../gcc-3.4.4/gcc/fixinc/fixincl.x:251: warning: string length `5139' is 
greater than the length `509' ISO C89 compilers are required to support
../../../gcc-3.4.4/gcc/fixinc/fixincl.x:2195: warning: string length `729' is 
greater than the length `509' ISO C89 compilers are required to support
../../../gcc-3.4.4/gcc/fixinc/fixincl.x:6357: warning: string length `575' is 
greater than the length `509' ISO C89 compilers are required to support
../../../gcc-3.4.4/gcc/fixinc/fixincl.c: In function `initialize':
../../../gcc-3.4.4/gcc/fixinc/fixincl.c:316: error: `SIGQUIT' undeclared 
(first use in this function)
../../../gcc-3.4.4/gcc/fixinc/fixincl.c:316: error: (Each undeclared 
identifier is reported only once
../../../gcc-3.4.4/gcc/fixinc/fixincl.c:316: error: for each function it 
appears in.)
../../../gcc-3.4.4/gcc/fixinc/fixincl.c:323: error: `SIGALRM' undeclared 
(first use in this function)
../../../gcc-3.4.4/gcc/fixinc/fixincl.c: In function `internal_fix':
../../../gcc-3.4.4/gcc/fixinc/fixincl.c:808: warning: implicit declaration of 
function `pipe'
../../../gcc-3.4.4/gcc/fixinc/fixincl.c:816: warning: implicit declaration of 
function `fork'
../../../gcc-3.4.4/gcc/fixinc/fixincl.c:845: warning: implicit declaration of 
function `sleep'
../../../gcc-3.4.4/gcc/fixinc/fixincl.c:860: warning: implicit declaration of 
function `fcntl'
../../../gcc-3.4.4/gcc/fixinc/fixincl.c:860: error: `F_DUPFD' undeclared 
(first use in this function)
../../../gcc-3.4.4/gcc/fixinc/fixincl.c: In function `process':
../../../gcc-3.4.4/gcc/fixinc/fixincl.c:1388: warning: implicit declaration of 
function `wait'
make[2]: *** [fixincl.o] Error 1
make[2]: Leaving directory `/home/MRT2LR/bgcc/gcc/fixinc'
make[1]: *** [fixinc.sh] Error 2
make[1]: Leaving directory `/home/MRT2LR/bgcc/gcc'
make: *** [all-gcc] Error 2


Is there also a fix for this available somewhere?

Is there anything else i can do?

Is there another way to set up gcc as a cross compiler with MinGW?
(Due to license issues i don't like to use cygwin).


Best regards,
Torsten.

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3318171
By: vergelter

>I suspect that for this to work you will need to 
> recompile libstdc++  with -fshort-enums. 
> The _Rb_tree_node bits are imported from 
> libstdc++ and they use the enum _Rb_tree_color. 

Is this a bug or a feature? The gcc-documentaion is
clear that code compiled with -fshort-enums 
is not binary compatible with other code. However,
it does not say whether libgcc or libstdc++ have to
be recompiled with this switch.

Normally I would guess that using incompatible 
enum layout makes programs using libgcc
or libstdc++ crash immediately. For some reason
it is very hard to find cases in which these crashes
occur (like the above one). Also, the program works
fine when compiled with MINGW gcc 2.3.2.

Any ideas?
Tim


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=286529

> I have tried my best to follow the instructions for installing first
> MSYS (I'm  used to bash courtesy of Mac OS X) and then I want to soon
> move on to MinGW.

I just had a look at the MinGWiki, "Getting started":
There it says Install MinGW to foo. Install MSYS to ...

IMO that means:
=2D first install MinGW
=2D secondly install MSYS.

Apart from the instructions at MinGWiki:
Knowing how the MSYS installer behaves I'd suggest you definitely
install MinGW first.

I don't know which instructions you followed but you may want
to try http://www.mingw.org/MinGWiki/index.php/GettingStarted

> Thanks a ton for any suggestions.

A short "now it works" would be sufficient... ;-)

HTH, best,
Michael
=2D-=20
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mg...@te...
 GPG-keys available on request or at public keyserver

Dear List,

I have tried my best to follow the instructions for installing first
MSYS (I'm  used to bash courtesy of Mac OS X) and then I want to soon
move on to MinGW. I ran the MSYS 1.0.11 exe installer (from snapshot)
and it works just fine (I'm installing on my XP Pro machine in
C:\tools\msys\1.0\  Next, I installed msysDTK (exe installer) version
1.0.1 ... no problems there that I'm aware of. Then, I install
msysDVLPR-1.0.0-alpha-1.tar.gz per the suggestions in the Wiki (I
followed the main installation, I do not follow the alternative
installation option) ... making sure to copy wincon.h as directed to
/usr/include, etc. (note: is /usr a symbolic link or something? I
can't find it when I cd to / and type "ls -al" but I can cd to /usr or
/usr/include

What I can't figure out exactly is what I should next install after
msysDVLPR? I tried the mingw runtime (being very careful to first run
msysdvlpr to get myself into a new shell which it then operate from
such that I'm in the MsysBuildEnvironment.

But here's where I get stumped -- I don't know what I try building and
installing next. I tried to configure, make and install the more
recent binutils (2.16.91 -- from Candidate) and even though configure
(with the options in the .sh works fine), make has a heart attack.
When I did so, I was very careful to follow the Wiki's suggestions
(e.g., create separate src and build directories and cook things in
the build directory as in configure ../src/.. ...)

Since that binutils didn't work, then tried to do the same for the
mingw-runtime-3.8 but again had problems with make (even with
configure, I wasn't sure what args to pass in so I kind of guessed by
looking at the args for binutils). Make didn' tlike the runtime 3.8
either.

I certainly don't yet have any of the mingw32-gcc, minggw32-g++, etc.
tools installed but does it make a difference? My preference is to
build everything from soruce if at all possible and using the .exe's
minimally (e.g., I had to use the exe installers for msys exe and
msysDTK exe). I really want to replace gcc that comes with msys (want
to use gcc candidate 3.4.x for example).

Any suggestions as to the order for building from source (after the
exes have been run) would be greatly appreciated. I have both /msys
and /mingw directories ready and rarin' to go. Did I miss something?

Thanks a ton for any suggestions.

Cheers,

-CK

version:
    mingw32-make 3.80-3

    If i pass a rule which is more than 200 characters long as a argument
to eval function, make gives message "mingw32-make: *** virtual memory
exhausted.  Stop." and passes through eval function without executing it.

I have attached a simple testcase makefile with this email.

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3315755
By: cc_benny

Hi Saar,

As the other poster said, this is standard C++.

The work-around is for stuff that you need to initialize before your baseclass
to put it into a second, private baseclass.   Baseclasses are initialized in
the order in which they are declared so you can do e.g. (warning: untested code
ahead):

class CMd4_FF_privates { 
protected: 
CMd4_FF_privates(CBinary* a, CBinary* b, CBinary* c, CBinary* d, CBinary* x); 

CBinaryBoolOp m_bc; 
CBinaryBoolNot m_nb; 
CBinaryBoolOp m_bd; 
CBinaryBoolOp m_bcd; 
CBinaryArithOp m_abcd; 
CBinaryArithOp m_abcdx; 
}; 
 
class CMd4_FF
  : private CMd4_FF_privates, public CBinaryRot { 
public: 
CMd4_FF(CBinary* a, CBinary* b, CBinary* c, CBinary* d, CBinary* x, int rotbits);
}; 

Add appropriate implementations for the constructors and you should get the
effect that you were after.
 

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=286529

Richard Gipps wrote:

>          Thanks for the reply.  What about if they both have to have '...'
> as the last argument i.e. func_two can be called from func_one as well as
> other places in the code?

You cannot do that directly.  But you can achieve what you want, just
make func_two_real (int, va_list) be the actual function and then write
a wrapper func_two (int, ...) that calls func_two_real.  This is exactly
what the C library does: printf, scanf, etc. are just wrappers that do
nothing but call vprintf, vscanf, etc.

Brian

Brian,
         Thanks for the reply.  What about if they both have to have '...' 
as the last argument i.e. func_two can be called from func_one as well as 
other places in the code?

Richard Gipps.

At 20:17 29/08/05, you wrote:
>Richard Gipps wrote:
> >
> > In C, is there any way you can call a variable argument function from
> > within another variable argument function and pass down the argument i.e.
>
>void
>func_two (int b, va_list ap)
>{
>   /* ... */
>   whatever = va_list (ap, type)
>   /* ... */
>}
>
>void
>func_one (int a, ...)
>{
>   va_list ap;
>
>   va_start (ap, a);
>   /* ... */
>   func_two (b, ap);
>   va_end (ap);
>}
>
>Most of the standard C library functions that take variadic arguments
>also have a 'v' version that accept a va_list instead: vprintf, vscanf,
>vsprintf, vsscanf, etc.
>
>Brian
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>_______________________________________________
>MinGW-users mailing list
>Min...@li...
>
>You may change your MinGW Account Options or unsubscribe at:
>https://lists.sourceforge.net/lists/listinfo/mingw-users

Richard Gipps wrote:
> 
> In C, is there any way you can call a variable argument function from
> within another variable argument function and pass down the argument i.e.

void
func_two (int b, va_list ap)
{
  /* ... */
  whatever = va_list (ap, type)
  /* ... */
}

void
func_one (int a, ...)
{
  va_list ap;  

  va_start (ap, a);
  /* ... */
  func_two (b, ap);
  va_end (ap);
}

Most of the standard C library functions that take variadic arguments
also have a 'v' version that accept a va_list instead: vprintf, vscanf,
vsprintf, vsscanf, etc.

Brian

In C, is there any way you can call a variable argument function from 
within another variable argument function and pass down the argument i.e.

func_one(int a,...) //<------------| pass args from here
{                          //             | 

     func_two(int b,...) //<--------| to here
}

Richard Gipps.

I have uploaded an update  of binutils (2.16.91-20050827-1)
to MinGW's Sourceforge File Release page. You can download it
from:

https://sourceforge.net/project/showfiles.php?group_id=2435

The 2.16.91-20050827-1 snapshot incorporates modifications to official 
binutils CVS since last update.

It also includes a patch by Filip Navara to support forward exports
in .def files passed to ld.exe.

Please refer ChangeLog entries in src for specific changes

For more info on binutils, follow this:
http://sources.redhat.com/binutils/

Danny

2005-08-28

> From: "Dave Murphy" <win...@nt...>
> Sent: 2005 August 27 Saturday 03:10
>
> Leif W wrote:
>
>> start again with all servers.  The point of mirrors is not to 
>> overload any single mirror by downloading everything from it.  Then 
>> maybe a
>
> The sourceforge mirror sites are given by region. I was under the 
> impression users should pick a mirror by closest geographical location 
> which would give best download speed and thus loading servers for less 
> time. It seems to me that if the point of the mirrors was load 
> balancing then the user wouldn't be given a choice

I am going by the prdownloads site.  It does not attempt to detect my 
region and list only close servers, though it could be done with GeoIP 
from MaxMind.  But anyways, geographic region has little to do with 
internet speed.  There are so many other variables that will make a 
machine next door run slower than one in eastern Europe or Japan at any 
given moment.  Could be network outages even.  Could even take 15 hops 
to go next door but only 5 to go around the world.  Network topology is 
more signifiganct that geography.  Sometimes servers don't have the 
file, though it's been released for months.  Odd things happen.

> do think that user management of sources is getting into territory 
> likely to confuse the end users of an "easy install system" for 
> windows.

Yeah, again, why I'd just consider a distinction between "Basic" and 
"Advanced" mode dialogs.  :p  Or at the least, check for a sources file 
and use it if available , otherwise fall back to the hard coded one.

>> Again, this sometimes does not work.  It may be the case that the 
>> "Current" version does not exist, it's only in "Candidate".  But if 
>> you choose "Candidate", you don't get what's in "Current".  Picking 
>> "most recent" should look for the most recent version in any release 
>> category.
>
> As I understand these terms, "previous" is the last stable version, 
> "current" is the present stable version, "candidate" is the most 
> recent (and bleeding edge).

It'd be nice if it was always like that but there are cases when it's 
not.  New releases, new versions of software which have been Candidates 
for a long time and at their last Candidate release, but not bumped to 
Current.  To get a completely updated toolset I need to pick from each 
category.

>> Ahh, this might suffice, but might be confusing.  We'd just have to 
>> see what happens.
>>
> Confusing in what way? Initial install and subsequent update seems

A new user reads that Candidate will give them the most recent thing, 
but they get only gcc and binutils, but if they need MSYS and that, 
they've got to go get current, then there's no version checking, so the 
Candidate stuff, is it there, is it blown away, are the versions 
compared and not install the older?

>> Hmm, there's the lacking versioning, dendency or conflict stuff in 
>> the .ini.  Can NSIS do numerical comparisons and such?  I imagine so, 
>> but don't know how it'd be specified.
>
> This could be implemented if necessary but again, I feel it's getting 
> away from an "easy installer" and moving towards a package manager 
> like

Easy install is one thing, and easy management is another, both equally 
useful.  It's very easy to install a tar ball.  Managing what's 
installed, what might be conflicting, that can become a bother.

> debian's apt. My experience with windows end users of gnu tools would 
> seem to indicate that the majority just want to click an installer and 
> have a complete toolchain they can program with - thus the popularity 
> of

Which is fine.  But then in 6 months or a year they might want to 
update.  Maybe update more frequently if something they need comes out. 
Without some kind of management tool a user might be back at square one 
having to figure out installs, which they already maybe wouldn't have 
learned, as they've become dependent on the installer as a crutch to 
hide the details.  :p

> Ultimately I think we have to balance ease of use from both sides of 
> the coin and my personal choice would be to go with a system that 
> causes least disruption to the people kindly donating their time to 
> provide the binary packages.

I don't want to create any extra work for anyone.  But I do not think a 
few lines describing version, dependency or conflict data in release 
notes (which must be given anyways) is too much to ask of a release 
manager.  But if it is, I'd at least maintain that info elsewhere.

In any case, ok, it's at least a step in the right direction to have a 
nice downloader and installer sans maintenance.

Leif

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3314573
By: chicares

> The calling of member and parent constructors is
> ordered specifically so that the parent class
> constructor is called after the members, causing the
> parent class to hold the final result of the calculation.

Compilers are required to disregard the order in which
you specify the initializers, and follow the order
mandated in paragraph 12.6.2/5 of the standard instead.

> However, the MinGW compiler insists, for no obvious
> reason, that the parent class be construct first, then
> the members in the order of their declaration.

That's the order required by the C++ standard. Here's
some discussion:
  http://www.gotw.ca/gotw/080.htm
and you can find more by searching the archives of
newsgroups like comp.lang.c++.moderated for the
paragraph cited above.


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=286529

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3314509
By: slugfiller

I have a calculation class definited as such:
	class CMd4_FF : public CBinaryRot {
	public:
		CMd4_FF(CBinary* a, CBinary* b, CBinary* c, CBinary* d, CBinary* x, int
rotbits);

	private:
		CBinaryBoolOp m_bc;
		CBinaryBoolNot m_nb;
		CBinaryBoolOp m_bd;
		CBinaryBoolOp m_bcd;
		CBinaryArithOp m_abcd;
		CBinaryArithOp m_abcdx;
	};

And constructed as such:
CMd4Transform::CMd4_FF::CMd4_FF(CBinary* a, CBinary* b, CBinary* c, CBinary*
d, CBinary* x, int rotbits):
	m_bc(b, c, 0),
	m_nb(b),
	m_bd(&m_nb, d, 0),
	m_bcd(&m_bc, &m_bd, 1),
	m_abcd(a, &m_bcd, 0),
	m_abcdx(x, &m_abcd, 0),
	CBinaryRot(&m_abcdx, rotbits)
{
}

(You may recognize this as a standard MD4_FF calculation)
The calling of member and parent constructors is ordered specifically so that
the parent class constructor is called after the members, causing the parent
class to hold the final result of the calculation.

However, the MinGW compiler insists, for no obvious reason, that the parent
class be construct first, then the members in the order of their declaration.
This little undocumented compiler "feature" causes an otherwise perfectly written
program crash.
It makes it impossible to make the calculation in the proper order, since the
parent class needs the sub-classes as it's constructed. Any alternative would
require not having the result in the parent class, but rather in a member class.
This has rather obvious disadvantages.

I've been trying to find a compiler option that would disable reordering, but
only managed to find one that gives a warning but keeps the reorder(yeah, that
helps alot...).
Quite frankly, I can't understand why MinGW insists on reordering the code,
even in a case where it obviously creates a bug that wasn't there originally.

If anyone knows how to disable this "feature", please let me know.


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=286529

Leif W wrote:

>
> Is it possible to code a unique random algorithm in NSIS?  With 
> mirrors a b c d, pick b at random, then pick from a c d at random, 
> test if the file exists on the server with a HEAD request, and get it 
> if it exists, or else pick another server, until run out, and then 
> start again with all servers.  The point of mirrors is not to overload 
> any single mirror by downloading everything from it.  Then maybe a 
> mirror is slow or has some problem, it might be handy to add/remove 
> sources (mirrors).

The sourceforge mirror sites are given by region. I was under the 
impression users should pick a mirror by closest geographical location 
which would give best download speed and thus loading servers for less 
time. It seems to me that if the point of the mirrors was load balancing 
then the user wouldn't be given a choice

It's certainly possible to allocate mirrors for download in a round 
robin or random fashion and even allow for input of a set of mirrors. I 
do think that user management of sources is getting into territory 
likely to confuse the end users of an "easy install system" for windows.

> Again, this sometimes does not work.  It may be the case that the 
> "Current" version does not exist, it's only in "Candidate".  But if 
> you choose "Candidate", you don't get what's in "Current".  Picking 
> "most recent" should look for the most recent version in any release 
> category.
>
As I understand these terms, "previous" is the last stable version, 
"current" is the present stable version, "candidate" is the most recent 
(and bleeding edge).

> Ahh, this might suffice, but might be confusing.  We'd just have to 
> see what happens.
>
Confusing in what way? Initial install and subsequent update seems 
perfectly straightforward to me.
Most of the groundwork for this installer was done on another project, 
the end users there have had no problems.

>
> Hmm, there's the lacking versioning, dendency or conflict stuff in the 
> .ini.  Can NSIS do numerical comparisons and such?  I imagine so, but 
> don't know how it'd be specified.

This could be implemented if necessary but again, I feel it's getting 
away from an "easy installer" and moving towards a package manager like 
debian's apt. My experience with windows end users of gnu tools would 
seem to indicate that the majority just want to click an installer and 
have a complete toolchain they can program with - thus the popularity of 
Dev-Cpp which includes an editor and protects people from the 
intricacies of makefiles.

Ultimately I think we have to balance ease of use from both sides of the 
coin and my personal choice would be to go with a system that causes 
least disruption to the people kindly donating their time to provide the 
binary packages.

Dave

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3313772
By: hoeppie

Hi,
it is needed to add C:/mingw/bin and C:/msys/1.0/bin to
your PATH.
You can do it with adding this line to your AUTOEXEC.BAT
SET PATH=C:/mingw/bin;C:/msys/1.0/bin;%PATH%


Regards DIrk

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=7134

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3313769
By: hoeppie

Hi Skymanager,
look here.
http://sourceforge.net/forum/forum.php?thread_id=1156975&forum_id=286533

If you like you can use my binary of libiconv  for compiling:
http://hoeppie.gmxhome.de/SWT/

Regards Dirk

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=286533

As a longtime (since 1999) albeit quiet user, I wanted to add my 
comments to this thread. I have helped a lot of new users setup and use 
MinGW and I think an easy installer would be great. The prototype NSIS 
installer looks very nice, although I did not run it all the way 
through--must finish Ph.D. =:^)

I greatly appreciate the work of the maintainers and think that adding 
a  lot of additional packages is a bad idea. If the NSIS installer can 
continue to use the existing (tarball) system and requires only an 
additional (and I suppose frequently updated) script somewhere, then 
that seems like the way to go. New users would still get a turnkey 
solution and there would be no change for those of us who are used to 
"tar -xvgf" to do updates. This may also make life easier for projects 
that build on MinGW (e.g., DevC++) as they could incorporate the same 
installer system for compiler/library updates.

FWIW--If you are going to make an installer that does all this, it seems 
that MSYS should also be included.

Nathan Masters
Woodruff School of Mechanical Engineering
Georgia Institute of Technology

> ...
> On first install this app will allow the user to pick a sourceforge
> mirror site and request download only or download and install. The
> second dialogue gives a choice of Previous, Current and Candidate
> packages moving on to pick individual components, install directory 
> and Start Menu.... A package maintainer would merely have to upload a new
> tarball and edit the appropriate line in the hosted ini file.
>
> For what it's worth the plugin used to extract the tarballs can also
> handle bzip2 and lzma compressed tarballs, both of which would reduce
> the size of the downloads.

On 2005-8-26 9:11 UTC, Foster Gareth wrote:
> 
> I am trying to use some code which allows you to launch programs from your
> code, its called libexecstream, it looks okay. Now, it provides something
> like ...
> 
> class c_exec_stream
> {
>   std::istream & out();
>   std::ostream & in()

No semicolon after the second function: illegal code may
occasionally give a mysterious "internal" error.

> };
> 
> 
> So, I try to do ...
> 
> c_exec_stream * p_exec_stream = new c_exec_stream("c:\\app.exe");
> 
> 
> Then, I try ...
> 
> std::copy	(
> 		std::istream_iterator(p_exec_stream->out()),
> 		std::istream_iterator(),
> 		std::ostream_iterator(std::cout)
> 	);

Post a complete, minimal, standalone testcase so that others can
reproduce the exact problem. For example:

#include <algorithm>
#include <iostream>
#include <istream>
#include <iterator>
#include <ostream>

class c_exec_stream
{
  public:
    std::istream & out();
    std::ostream & in();
};

c_exec_stream * p_exec_stream;// = new c_exec_stream("c:\\app.exe");

int main()
{
    std::copy
        (
        std::istream_iterator<double,char>(p_exec_stream->out()),
        std::istream_iterator<double,char>(),
        std::ostream_iterator<double,char>(std::cout, "\n")
        );
}

That doesn't seem to fail, though. Maybe I added something that
kept it from producing the error; it's hard to guess.

> Which ought to work right? Well I get ...
>
> file.cc: In constructor `myclass::myclass()':
> file.cc:48: internal compiler error: in finish_class_member_access_expr, at
> cp/typeck.c:1941
> Please submit a full bug report,
> with preprocessed source if appropriate.

You'll need a complete standalone testcase to report that anyway.
The gcc maintainers might not give it much attention if the code
is invalid, even though even that would ideally not give an ICE.
If an ICE results from valid code, that's a bigger concern.

----- Original Message ----- 
From: "Foster Gareth" <gar...@si...>
To: <min...@li...>
Sent: Friday, August 26, 2005 5:11 PM
Subject: [Mingw-users] std::istream & istream_iterators


> 'ello,
>
> I am trying to use some code which allows you to launch programs from your
> code, its called libexecstream, it looks okay. Now, it provides something
> like ...
>
> class c_exec_stream
> {
>  std::istream & out();
>  std::ostream & in()
> };
>
>
> So, I try to do ...
>
> c_exec_stream * p_exec_stream = new c_exec_stream("c:\\app.exe");
>
>
> Then, I try ...
>
> std::copy (
> std::istream_iterator(p_exec_stream->out()),
> std::istream_iterator(),
> std::ostream_iterator(std::cout)
> );
>
>
> Which ought to work right? Well I get ...
>
> file.cc: In constructor `myclass::myclass()':
> file.cc:48: internal compiler error: in finish_class_member_access_expr, 
> at
> cp/typeck.c:1941
> Please submit a full bug report,
> with preprocessed source if appropriate.
>
>
> I've tried variations, like copy to a vector, or a string, it has the same
> result in each case. What is going off? Should this compile?
>
> Cheers all,
>
>
> Gaz

See http://www.mingw.org/bugs.shtml

If you are not using the latest release of the compiler, then please try 
updating first.

Luke

> From: <14f...@sn...>
> Sent: 2005 August 26 Friday 06:03
>

> guy wants is to download eclipse and MinGW, and install them. that's 
> it. There's nothing wrong with that, is it?

Nope, nothing wrong with that.  :p

> Think of it this way: the newbes of today are the 
> maintainers/contributors of tomorrow - why? because the use a tool, 
> find it nice, and use it again. And then, they might want give 
> something back to the community.

Well, put on my salty dog (sarcasm) hat, the ones who would go on to 
contribute would not need any installer.  They'd instinctively know what 
to download.  :p

> I don't think a command line installer is the way to go. It's just not 
> user friendly.

Well, I actually thought it was pretty cool idea.  :p  It's much easier 
to make a command line unfriendly, true, but it's also possible to make 
it simple, elegant and powerful (scriptable), so that I could for 
instance schedule automatic updates or something, if I were so inclined 
to maintain a bleeding edge toolset.

> How would you choose installation paths, for instance? by command line 
> argument? or a prompt?

Prompt on first run, maybe give a list of possible locations by looking 
at environment variables and system language, store to config file for 
subsequent runs without prompting.

> the user won't have a list of available packages (ok, unless you put 
> loads of commandline options into the installer and again make it 
> really complex to use

Well, print lists, pick a number.  In the console world, there is no 
windows registry, and text programs can be very comfortable.  So I fully 
understand that idea.  But this isn't a console OS, so I understand the 
aprehension as well of those accustomed to GUIs.  I think both would 
complement each other.  Not necessarily all in the same tool.

Leif