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

On Fri, Oct 01, 2004 at 08:35:41AM +1200, Danny Smith wrote:
> Ian D. Gay wrote:
> >> Using MinGW-3.1.0-1 out of the box, installed by windows install
> >> program, fortran programs will compile but not link. The link stage
> >> of
> >> gcc fails with undefined references to s_wsle, do_lio, e_wsle, s_stop
> >> and winMain@16.
> >>
> >> This error can be cured by linking with libg2c and libfrtbegin.
> 
> Even better, use g77, rather than gcc to compile and link,  This is
> documented:
> 

On my system, after default install,
C:\source\test> g77 zap.f
g77: installation problem, cannot exec `f771': No such file or 
directory.

Now this can no doubt be fixed by adjusting PATH, but it still doesn't 
work out of the box.

Ian

Ian D. Gay wrote:
>> Using MinGW-3.1.0-1 out of the box, installed by windows install
>> program, fortran programs will compile but not link. The link stage
>> of
>> gcc fails with undefined references to s_wsle, do_lio, e_wsle, s_stop
>> and winMain@16.
>>
>> This error can be cured by linking with libg2c and libfrtbegin.

Even better, use g77, rather than gcc to compile and link,  This is
documented:

   "The `g77' command is essentially just a front-end for the `gcc'
command.  Fortran users will normally use `g77' instead of `gcc',
because `g77' knows how to specify the libraries needed to link with
Fortran programs (`libg2c' and `lm').  `g77' can still compile and link
programs and source files written in other languages, just like `gcc'."

in g77.info


Danny

Using MinGW-3.1.0-1 out of the box, installed by windows install 
program, fortran programs will compile but not link. The link stage of 
gcc fails with undefined references to s_wsle, do_lio, e_wsle, s_stop 
and winMain@16.

This error can be cured by linking with libg2c and libfrtbegin. As far 
as I can see, this is not documented anywhere, and is not in the faq. 
It would be nice if it were documented, so new users can find it more 
easily than I did.

It would be even nicer if it just worked out of the box. This can be 
done by modifying the specs file appropriately. I have a specs file 
which appears to work for fortran and doesn't break C. (Haven't tested 
C++). I'd be happy to contribute this to the project, if someone tells 
me where to send it.

Ian

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

 > The important thing to understand is that 
 > this is not done by the
 > function but by the underlying 
 > file system layer. It sees a '\n'
 > character in text mode and it 
 > automatically inserts a '\r' as well.
 > This is a feature of the operating system.

No it isn't. It is a feature of the Microsoft C library. The _write() function
in the C library translates \n to \r\n for files open in text mode. The operating
system (Windows) does no kind of translation, and knows no difference between
files open in "text" or "binary" modes.


______________________________________________________________________
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=290275

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

You didn't bother to mention what your command line options were.  Is this is
debug build, or optimized?  In either case, did you strip the final executable?

Are you actually using any c++ code in your program?  If so, do you use any
of the library functions. e.g.: some part of iostream, or STL?  If that is the
case, search the archives of the mailing list, it is well documented.

Cheers,

Andrew.

______________________________________________________________________
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=286641

On Thu, 30 Sep 2004 13:04:50 +0100
Keith MARSHALL <kei...@to...> wrote:

> Any directory in the PATH should do.  Normally, Windows will put its own
> system directory in PATH, which is why your use of %SYSTEMROOT%/System32
> would have worked, in your original setup.  Adding /usr/local/lib to the
> PATH, and putting the DLLs there would also work, *but* it is rather
> unconventional -- this directory is normally used for libraries to be
> *statically* linked to your apps, and is not normally included in PATH.

Yep, I suppose that makes sense. /usr/local/bin it is then.

> On Linux, it may also contain .so libraries, (the Linux equivalent of
> DLLs), but then Linux has a different mechanism for locating them,
> which is independent of any PATH search.

Actually Linux is what I am most familiar with. This is the first
windows coding I've done since 1999.

Thanks for your help.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  no...@me... (Yes it's valid)
+-----------------------------------------------------------+
I have found that good programmers either do not make the kind
of mistakes that Ada can prevent, or insert enough checks that
they catch those mistakes about as efficiently as an Ada
environment can. At that point, the use of Ada gives no further
productivity advantage.

On Thu, Sep 30, 2004 at 04:54:59AM -0700, Vivek Jishtu wrote:
> This is just a sample code that compiles using the
> Microsoft C++ compiler but seems to be giving problems
> when compiled in Dev-C++. The problem is that I am
> trying to port a library to Mingw but this kind of
> functionality has been used in the library and I am
> getting all sorts or wierd errors because of this.
> 
> What am I missing out?

It would help if you showed the errors.

> Regards,
> Vivek Jishtu
> 
> ------------------------------------------------
> 
> #include <iostream>
> 
> class First{
> 
> public:
>      void SomeWork()
>      {
>         std::cout <<"Inside SomeWork";
>      }
> };
> 
> class Second
> {
> 
> public:
>     void myfun(First &obj)
>     {
>       obj.SomeWork();
>     }
> };
> 
> int main()
> {
>  Second Obj2;
>  Obj2.myfun(First());


I don't think it is allowed to pass a temporary
to a function taking a non-const reference.

>  return 0;
> }

Try using

#include <iostream>

class First{

public:
     void SomeWork() const
     {
        std::cout <<"Inside SomeWork";
     }
};

class Second
{

public:
    void myfun(First const& obj)
    {
      obj.SomeWork();
    }
};

int main()
{
 Second Obj2;
 Obj2.myfun(First());
 return 0;
}


-- 
Carlo Wood <ca...@al...>

Erik de Castro Lopo wrote:
>> IMO, this is the best approach.  If you are using MSYS, then a good
>> place for any command line apps you want to install would be
>> /usr/local/bin (or /local/bin, which is the same place, due to the
>> way MSYS 'mounts' /usr).  When these apps need DLLs, for their use
>> only, then put these in /usr/local/bin too.  Set your PATH up so that
>> /usr/local/bin is searched, in whatever order you prefer, and not only
>> will the shell be able to find your apps, but those apps will also
>> find their DLLs.
> 
> Well /usr/local/bin already works for the apps if I put the DLL
> in the windows system directory, but now I think I should put
> the DLL in /usr/local/bin.

That would be my choice.
 
>> IMO, this is not as clean as simply keeping the DLLs and apps
>> together, in a common bin directory on the path -- /usr/local/bin is,
>> after all, provided for users' locally installed apps, so would seem
>> to fit the bill nicely.  Requiring the user to type
>> 
>>    PATH="$PATH:path/to/myDLLs" myapp ...
> 
> Would it be possible to add /usr/local/lib to the PATH variable
> and have that work? That tends to make a little more sense.

Any directory in the PATH should do.  Normally, Windows will put its own
system directory in PATH, which is why your use of %SYSTEMROOT%/System32
would have worked, in your original setup.  Adding /usr/local/lib to the
PATH, and putting the DLLs there would also work, *but* it is rather
unconventional -- this directory is normally used for libraries to be
*statically* linked to your apps, and is not normally included in PATH.
On Linux, it may also contain .so libraries, (the Linux equivalent of
DLLs), but then Linux has a different mechanism for locating them,
which is independent of any PATH search.

HTH.

Keith.

This is just a sample code that compiles using the
Microsoft C++ compiler but seems to be giving problems
when compiled in Dev-C++. The problem is that I am
trying to port a library to Mingw but this kind of
functionality has been used in the library and I am
getting all sorts or wierd errors because of this.

What am I missing out?

Regards,
Vivek Jishtu

------------------------------------------------

#include <iostream>

class First{

public:
     void SomeWork()
     {
        std::cout <<"Inside SomeWork";
     }
};

class Second
{

public:
    void myfun(First &obj)
    {
      obj.SomeWork();
    }
};

int main()
{
 Second Obj2;
 Obj2.myfun(First());
 return 0;
}


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

On Thu, 30 Sep 2004 10:52:40 +0100
Keith MARSHALL <kei...@to...> wrote:

> In reply to Erik de Castro Lopo, Michael Gerdau wrote:

Is there some reason I didn't see Michael's reply on the mailing
list?

> > IMO it is *VERY*BAD*PRACTICE* to install anything in 
> C:\WINDOWS\SYSTEM32\
> > other than the plain vanilla OS-DLLs.
> 
> I agree with Michael on this.

I agree, but it was the first solution I found that worked :-).

> > IMO the DLLs you need for your app should go in the same (separate)
> > dir where you install the executable (or some fixed relative path
> > from there in case you load the DLLs dynamically).

Well I don't load the DLL dynamically so .....

> IMO, this is the best approach.  If you are using MSYS, then a good
> place for any command line apps you want to install would be
> /usr/local/bin (or /local/bin, which is the same place, due to the
> way MSYS 'mounts' /usr).  When these apps need DLLs, for their use
> only, then put these in /usr/local/bin too.  Set your PATH up so that
> /usr/local/bin is searched, in whatever order you prefer, and not only
> will the shell be able to find your apps, but those apps will also
> find their DLLs.

Well /usr/local/bin already works for the apps if I put the DLL
in the windows system directory, but now I think I should put
the DLL in /usr/local/bin.

> IMO, this is not as clean as simply keeping the DLLs and apps
> together, in a common bin directory on the path -- /usr/local/bin is,
> after all, provided for users' locally installed apps, so would seem
> to fit the bill nicely.  Requiring the user to type
> 
>    PATH="$PATH:path/to/myDLLs" myapp ...

Would it be possible to add /usr/local/lib to the PATH variable
and have that work? That tends to make a little more sense. 

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  no...@me... (Yes it's valid)
+-----------------------------------------------------------+
"Ever since GNOME development began, I have urged people to aim
to make it as good as the Macintosh. To try to be like Windows
is to try for second-best." - Richard Stallman

On Thu, 30 Sep 2004 02:46:43 -0700
"SourceForge.net" <no...@so...> wrote:

>=20
> Read and respond to this message at:=20
> https://sourceforge.net/forum/message.php?msg_id=3D2782655
> By: ivanrolim
>=20
> I=B4ve been playing around the win32 functions with a manual, I don=B4t l=
ike MFC
> and etc.., all is done using API only. However, my EXE code is still very=
 high
> (700k for one window with just ONE button only, for example).

Have you tried stripping the binary?

> Everyone knows C++ uses only part of a library,=20

Are you using any C++ language features or is this really C?
If its C, try compiling with gcc instead of g++.

Are you using any C++ STL features? If so, see the FAQ.

> via include files, but if code
> size is still high, I want to know what the heck is going on :( It=B4s ju=
st a
> non-optimized windows.h?

That header itself generates almost no code apart from a very
limited number of macros.

Erik
--=20
+-----------------------------------------------------------+
  Erik de Castro Lopo  no...@me... (Yes it's valid)
+-----------------------------------------------------------+
"Indeed, I am impressed that Google runs an 8,000 node Linux
cluster, 5 data centers, an extensive network, and a rapidly
evolving application all with a staff of 12."
  -- http://research.microsoft.com/~gray/papers/FAAMs_HPTS.doc

In reply to Erik de Castro Lopo, Michael Gerdau wrote:
>> I am now at the stage where I am adding a "make install" target
>> and I'm wondering what people think of the idea of installing
>> DLLs directly into C:\WINDOWS\SYSTEM32\ so the application can
>> find it when it is installed in /usr/local/bin. 
>> 
>> Is this a bad idea? Is there another way to achieve the same 
>> results?
> 
> IMO it is *VERY*BAD*PRACTICE* to install anything in 
C:\WINDOWS\SYSTEM32\
> other than the plain vanilla OS-DLLs.

I agree with Michael on this.

> M$ and quite a few ISV are guilty of violating this.
> This regularly results in incompatibilities between versions
> of the same DLLs (two software products are installing the same
> DLL, one overwriting the other, when you are lucky you keep the
> newer one but if some software requires the older version and the
> newer is incompatible it suddenly stops working).
> 
> Another problem is that this practice requires administrator
> rights to install the software. If you are security aware you
> don't want that.
> 
> IMO the DLLs you need for your app should go in the same (separate)
> dir where you install the executable (or some fixed relative path
> from there in case you load the DLLs dynamically).

IMO, this is the best approach.  If you are using MSYS, then a good
place for any command line apps you want to install would be
/usr/local/bin (or /local/bin, which is the same place, due to the
way MSYS 'mounts' /usr).  When these apps need DLLs, for their use
only, then put these in /usr/local/bin too.  Set your PATH up so that
/usr/local/bin is searched, in whatever order you prefer, and not only
will the shell be able to find your apps, but those apps will also
find their DLLs.

> If you *really* need to have your DLLs available to every other
> program on the system (which I suppose you don't) you could always
> add the installation dir _at_the_end_ of the PATH variable.
> 
> Depending on how you start your app you could also consider to
> setup the environment on the fly -- the drawback is this requires
> quite some additional work on your part which might not be trivial
> in all situations. But that definitely would be the cleanest thing
> to do.

IMO, this is not as clean as simply keeping the DLLs and apps
together, in a common bin directory on the path -- /usr/local/bin is,
after all, provided for users' locally installed apps, so would seem
to fit the bill nicely.  Requiring the user to type

   PATH="$PATH:path/to/myDLLs" myapp ...

or anything similar, to set up the environment on the fly, doesn't
seem clean to me -- even if it is stored in a Windows "shortcut".
The other alternative, of hard coding paths to DLLs into the app
itself, is also undesirable, IMO.

HTH.

Best regards,
Keith.

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

I´ve been playing around the win32 functions with a manual, I don´t like MFC
and etc.., all is done using API only. However, my EXE code is still very high
(700k for one window with just ONE button only, for example).

Everyone knows C++ uses only part of a library, via include files, but if code
size is still high, I want to know what the heck is going on :( It´s just a
non-optimized windows.h?

Thanks :)

______________________________________________________________________
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=286641

> I am now at the stage where I am adding a "make install" target
> and I'm wondering what people think of the idea of installing
> DLLs directly into C:\WINDOWS\SYSTEM32\ so the application can
> find it when it is installed in /usr/local/bin. 
> 
> Is this a bad idea? Is there another way to achieve the same 
> results?

IMO it is *VERY*BAD*PRACTICE* to install anything in C:\WINDOWS\SYSTEM32\
other than the plain vanilla OS-DLLs.

M$ and quite a few ISV are guilty of violating this.
This regularly results in incompatibilities between versions
of the same DLLs (two software products are installing the same
DLL, one overwriting the other, when you are lucky you keep the
newer one but if some software requires the older version and the
newer is incompatible it suddenly stops working).

Another problem is that this practice requires administrator
rights to install the software. If you are security aware you
don't want that.

IMO the DLLs you need for your app should go in the same (separate)
dir where you install the executable (or some fixed relative path
from there in case you load the DLLs dynamically).

If you *really* need to have your DLLs available to every other
program on the system (which I suppose you don't) you could always
add the installation dir _at_the_end_ of the PATH variable.

Depending on how you start your app you could also consider to
setup the environment on the fly -- the drawback is this requires
quite some additional work on your part which might not be trivial
in all situations. But that definitely would be the cleanest thing
to do.

Best,
Michael
-- 
 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 all,

I have three libraries say, libx, liby and libz and a bunch of 
applications which depend on one or more of the libraries. All 
three libs are originally Unix libs built with autoconf, automake 
and libtool. 

For win32 I have not been able to create a DLL with the standard
tools, so I have a custom Makefile.mingw.in for each lib and 
let the configure script generate Makefile.mingw which creates
a DLL by defailt instead of a static lib.

I am now at the stage where I am adding a "make install" target
and I'm wondering what people think of the idea of installing
DLLs directly into C:\WINDOWS\SYSTEM32\ so the application can
find it when it is installed in /usr/local/bin. 

Is this a bad idea? Is there another way to achieve the same 
results?

Cheers,
Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  no...@me... (Yes it's valid)
+-----------------------------------------------------------+
"It's not that perl programmers are idiots, it's that the
language rewards idiotic behavior in a way that no other
language or tool has ever done." --  Erik Naggum

>I'm thinking perhaps targmatch.sed has \r\n line endings perhaps.
>I'll download the binutils source tomorrow and give it a shot.
>Earnie

Indeed, I found on the web that there is a known bug of sed when line
endings are not in unix format.

I changed targmatch.sed format, and could build binutils and get a
working libaddr2line.a

Thanks

Nicolas

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

This function isn't in libgdi32.a. It is supported since win2000. See also
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontext_4sv
n.asp

______________________________________________________________________
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=286641

I'm thinking perhaps targmatch.sed has \r\n line endings perhaps.

I'll download the binutils source tomorrow and give it a shot.

Earnie

Nicolas Brunot wrote:

>>Just what is the problem?  Which version of MSYS?
>>Earnie
>>    
>>
>
>I tried 
>MSYS-1.0.10.exe and MSYS-1.0.11-2004.04.30-1.exe
>with msysDTK-1.0.1.exe
>
>I get
>
>./binutils-2.15.91-20040904-1/bfd/../intl -I../intl   -W -Wall
>-Wstrict-prototypes -Wmissing-prototypes -O2 -fno-excepti
>ons -c ../../binutils-2.15.91-20040904-1/bfd/syms.c
>gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.15.91-20040904-1/bfd -I.
>-D_GNU_SOURCE -D__USE_MINGW_FSEEK -I. -I../../binuti
>ls-2.15.91-20040904-1/bfd
>-I../../binutils-2.15.91-20040904-1/bfd/../include
>-I../../binutils-2.15.91-20040904-1/bfd/../
>intl -I../intl -W -Wall -Wstrict-prototypes -Wmissing-prototypes -O2
>-fno-exceptions -c ../../binutils-2.15.91-20040904-
>1/bfd/syms.c -o syms.o
>rm -f targmatch.h
>sed -f ../../binutils-2.15.91-20040904-1/bfd/targmatch.sed <
>../../binutils-2.15.91-20040904-1/bfd/config.bfd > targmatc
>h.new
>sed: file ../../binutils-2.15.91-20040904-1/bfd/targmatch.sed line 1:
>Extra characters after command
>make[3]: *** [targmatch.h] Error 1
>make[3]: Leaving directory `/build/bfd'
>make[2]: *** [all-recursive] Error 1
>make[2]: Leaving directory `/build/bfd'
>make[1]: *** [all-recursive-am] Error 2
>make[1]: Leaving directory `/build/bfd'
>make: *** [all-bfd] Error 2
>sh-2.04$
>
>
>
>
>  
>

-- 
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

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

Mikael posted how to change this. The important thing to understand is that
this is not done by the function but by the underlying file system layer. It
sees a '\n' character in text mode and it automatically inserts a '\r' as well.
This is a feature of the operating system. Other operating systems that do not
use a plain '\n', e.g. MacOS, work similarly.

The idea behind this is to make file reading/writing portable across operating
systems. Just use '\n' in your code, then let the underlying file system drivers
take care of the rest.

______________________________________________________________________
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=290275

>Just what is the problem?  Which version of MSYS?
>Earnie

I tried=20
MSYS-1.0.10.exe and MSYS-1.0.11-2004.04.30-1.exe
with msysDTK-1.0.1.exe

I get

./binutils-2.15.91-20040904-1/bfd/../intl -I../intl   -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -O2 -fno-excepti
ons -c ../../binutils-2.15.91-20040904-1/bfd/syms.c
gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.15.91-20040904-1/bfd -I.
-D_GNU_SOURCE -D__USE_MINGW_FSEEK -I. -I../../binuti
ls-2.15.91-20040904-1/bfd
-I../../binutils-2.15.91-20040904-1/bfd/../include
-I../../binutils-2.15.91-20040904-1/bfd/../
intl -I../intl -W -Wall -Wstrict-prototypes -Wmissing-prototypes -O2
-fno-exceptions -c ../../binutils-2.15.91-20040904-
1/bfd/syms.c -o syms.o
rm -f targmatch.h
sed -f ../../binutils-2.15.91-20040904-1/bfd/targmatch.sed <
../../binutils-2.15.91-20040904-1/bfd/config.bfd > targmatc
h.new
sed: file ../../binutils-2.15.91-20040904-1/bfd/targmatch.sed line 1:
Extra characters after command
make[3]: *** [targmatch.h] Error 1
make[3]: Leaving directory `/build/bfd'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/build/bfd'
make[1]: *** [all-recursive-am] Error 2
make[1]: Leaving directory `/build/bfd'
make: *** [all-bfd] Error 2
sh-2.04$

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

OK.

You're not really supposed to do that, as they're not really entirely the same
thing.

For example, note that msvcr70.dll isn't the same thing as msvcrt.dll, even
though they're both version 7.0 of the CRT.

Its sort of a confusing situation.  Misunderstanding of this sort is a lot of
what lead to 'DLL hell' in the first place.  Microsoft cites it as a major reason
Windows 9x systems were so unreliable.

Aaron W. LaFramboise


______________________________________________________________________
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=2780473
By: neo_in_matrix

OK, its original name is msvcrt71.dll. I think I renamed it to msvcrt.dll. But
everything works just fine for both my Windows 2000 Pro and Windows XP Pro.

BTW, the two systems are installed on the same computer. I think I renamed
msvcrt71.dll to msvcrt.dll for each of them when I booted into the other system.

______________________________________________________________________
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=2780381
By: aaronwl

Well, I haven't heard back from you.  I didn't see whatever sort of file was
posted.

What I'd like to know is if this is really msvcrt.dll, and not something else,
like msvcr71.dll, that got renamed to msvcrt.dll.  I don't entirely understand
Microsoft's new rules on this, but its my understanding that msvcrt.dll can
only be replaced by the system (whatever that means).

I have Windows XP SP2, yet it only has a version 7.0, so I'm a little confused
how some other installation might have a 7.1, unless it was something that got
renamed from msvcr71.dll or something.

You can tell the original name of most Microsoft DLLs by looking at file properties,
on the version tab, for the entry "Internal Name."  If you could let me know
what this is, I'd appreciate it.

Aaron W. LaFramboise


______________________________________________________________________
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

Nicolas Brunot wrote:

>I quickly tried to generate it myself, but binutils doesn't build out of
>the box with msys, and I don't want to use cygwin
>
>  
>
Just what is the problem?  Which version of MSYS?

Earnie

-- 
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

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

I've removed the post with the BASE64 text.  Please do not distribute microsoft
dlls via this or any other MinGW list.

Earnie

______________________________________________________________________
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