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

Posted on DATE by AUTHOR Aaron W. LaFramboise
> While we're talking about it, would anybody be interested in having
> MinGW provide the C++ <cxxx> headers rather than libstdc++-v3?
>
--8<--
>
> Such an implementation would allow conformance in an area that almost no
> compilers get right, including GNU/Linux, which I think would be pretty
> cool.
>
> Comments?
>

Such an addition could be handled nicely by a new library package.  Let me
know if you want me to setup a CVS module.  The question would be the name
of the library?  Options for g++?  Anything else?

Earnie

Earnie Boyd wrote:
> Posted on DATE by AUTHOR Danny Smith
>> Steve Lee wrote:
>>>> Because limits is not part of the mingw runtime, but part of
>>>> whatever C++ library you are using.
>>>> 
>>>> One fix would be to make __int64 either a builtin intrinsic type
>>>> or a builtin macro for mingw.  That would need a patch to gcc. 
>>>> But to be consistent you woud probably also want the other MS-ism
>>>> types to be predefined as well. Where does it stop?.
>>> 
>>> But if you #include <limits.h> (or *.h) _mingw.h IS included and so
>>> is __int64 and others. limits.h is part of C standard library so
>>> surely your argument applies to that too? Someone has decided that
>>> those MS extensions are worth defining when using the C libs so why
>>> not for CPP? But yes I agree it is not really part of the library
>>> at all! 
>>> 
>> 
>> 
>> Adding an #include <_mingw.h> to
>> include/c++/3.4.2/mingw32/bits/os_defines.h
>> should work.for GCC's libstdc++
> 
> Danny, are you proposing this as an official patch for libstdc++?

No.  This is the wrong list for doing that.
Danny

> 
> Earnie
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
> 
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users

While we're talking about it, would anybody be interested in having
MinGW provide the C++ <cxxx> headers rather than libstdc++-v3?

The primary advantage here is that this is the only way we can get
complete compliance with the C++ standard.  In particular, currently, on
every libstdc++-v3 system where the C standard library doesn't also
provide the <cxxx> headers, C symbols are incorrectly injected into the
global namespace, which is a violation of the C++'s standard on
implmntations.  (Note that there is some discussion of a future C++
standard loosening this requirement, but that wouldn't change C++ '98.)

Another advantage is that we can get get correct behavior in the
presence of including combinations of <xxx.h> and <cxxx>.

A while back, I wrote some parts of a special-purpose standard C library
implementation, and I used this strategy, so I know it works.  It is
quite easy to implement.  One tricky part is that some <cxxx> headers
provide overloaded C++ functions that aren't in C, and we don't want to
make mingw-runtime dependent on C++.  The easy solution here is inline
functions that delegate to C99 equivilents.

The way I implemented it was to have the <xxx.h> header place its
declarations into both the global and standard namespace.  The <cxxx>
header is just a wrapper that temporarily defines a special macro that
inhibits <xxx.h> from defining macros in the global namespace.

Such an implementation would allow conformance in an area that almost no
compilers get right, including GNU/Linux, which I think would be pretty
cool.

Comments?

Aaron W. LaFramboise

Posted on DATE by AUTHOR Danny Smith
> Steve Lee wrote:
>>> Because limits is not part of the mingw runtime, but part of whatever
>>> C++ library you are using.
>>>
>>> One fix would be to make __int64 either a builtin intrinsic type or a
>>> builtin macro for mingw.  That would need a patch to gcc.  But to be
>>> consistent you woud probably also want the other MS-ism types to be
>>> predefined as well. Where does it stop?.
>>
>> But if you #include <limits.h> (or *.h) _mingw.h IS included and so is
>> __int64 and others. limits.h is part of C standard library so surely
>> your argument applies to that too? Someone has decided that those MS
>> extensions are worth defining when using the C libs so why not for
>> CPP? But yes I agree it is not really part of the library at all!
>>
>
>
> Adding an #include <_mingw.h> to
> include/c++/3.4.2/mingw32/bits/os_defines.h
> should work.for GCC's libstdc++

Danny, are you proposing this as an official patch for libstdc++?

Earnie

Steve Lee wrote:
>> Because limits is not part of the mingw runtime, but part of whatever
>> C++ library you are using.
>>
>> One fix would be to make __int64 either a builtin intrinsic type or a
>> builtin macro for mingw.  That would need a patch to gcc.  But to be
>> consistent you woud probably also want the other MS-ism types to be
>> predefined as well. Where does it stop?.
>
> But if you #include <limits.h> (or *.h) _mingw.h IS included and so is
> __int64 and others. limits.h is part of C standard library so surely
> your argument applies to that too? Someone has decided that those MS
> extensions are worth defining when using the C libs so why not for
> CPP? But yes I agree it is not really part of the library at all!
>


Adding an #include <_mingw.h> to
include/c++/3.4.2/mingw32/bits/os_defines.h
should work.for GCC's libstdc++

Danny

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

Sorry? I don't understand the question?

Any of the functions that you want to access that are exposed via COM can only
be accessed via COM. To call such a funciton you have to go through various
steps calling standard COM functions to get a 'handle' (pointer or ID) to the
function you want and then call it. COM DLLS export the standard COM functions
you saw to provide this mechanism.

What are the functions that you want to call and how do you know they exists?

Steve

______________________________________________________________________
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

> Because limits is not part of the mingw runtime, but part of whatever
> C++ library you are using.
> 
> One fix would be to make __int64 either a builtin intrinsic type or a
> builtin macro for mingw.  That would need a patch to gcc.  But to be
> consistent you woud probably also want the other MS-ism types to be
> predefined as well. Where does it stop?.

But if you #include <limits.h> (or *.h) _mingw.h IS included and so is 
__int64 and others. limits.h is part of C standard library so surely 
your argument applies to that too? Someone has decided that those MS 
extensions are worth defining when using the C libs so why not for CPP? 
But yes I agree it is not really part of the library at all!

>>
>>I want the definition of __int64 and other MS extensions but don't
>>really what to change code to explicitly include _mingw.h or define
>>myself.
> 
> 
> I want a cold beer.

LOL! Ok I asked for that! I prefer English warm suds!

Steve

Please have a look on these pages:

http://www.mingw.org/MinGWiki/index.php/create%20import%20DLL-libraries

and

http://www.mingw.org/mingwfaq.shtml#faq-msvcdll

Henrik.

----Original Message Follows----
From: Jack Chen <jac...@ya...>
Reply-To: min...@li...
To: min...@li...
Subject: [Mingw-users] Linking files compiled with Visual Studio 7 (.net) 
question
Date: Sun, 31 Oct 2004 12:11:32 -0500 (EST)

Hi, dear list members,

Just a simple question. How can I link .lib and .dll files compiled
with Visual Studio 7 (.net)? What additional words should I type at the
command line?

Thank you in advance for your help.

Jack

______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
MinGW-users mailing list
Min...@li...

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_________________________________________________________________
Få alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk/

Hi, dear list members,

Just a simple question. How can I link .lib and .dll files compiled
with Visual Studio 7 (.net)? What additional words should I type at the
command line?

Thank you in advance for your help.

Jack

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

Steve Lee wrote:
> Is there a good reason why the cpp library header files (without .h)
> do not #include <_mingw.h> (or equivalent of)?
>
> For example why should I not expect the following to compile
>
> #include <limits>
>
> #ifndef __int64
>      #error should be defined
>      // works with <limits.h>
> #endif

Because limits is not part of the mingw runtime, but part of whatever
C++ library you are using.

One fix would be to make __int64 either a builtin intrinsic type or a
builtin macro for mingw.  That would need a patch to gcc.  But to be
consistent you woud probably also want the other MS-ism types to be
predefined as well. Where does it stop?.

>
>
> I want the definition of __int64 and other MS extensions but don't
> really what to change code to explicitly include _mingw.h or define
> myself.

I want a cold beer.

Danny
>
> SteveLee

Hi,
Actually I moved the stlport CXXFLAGS to the CPPFLAGS (which come before 
CXXFLAGS) and it was fixed,
I though the CPLUS_INCLUDE_PATH directories were the first to be searched 
for includes, this seems not to be the case,
the order probably is -I defined paths, CPLUS_INCLUDE_PATH, then default 
paths, is that correct?

Anyway, thanks for the help :)

At 10:03 PM 10/27/2004, you wrote:
>Rodrigo Hernandez wrote:
> > Hello All,
> >
> > I am "porting" Nel (www.nevrax.org) to MSYS+MinGW and I stumbled upon
> > a problem were I get a #include nested too deeply error from STLport,
> > this is due to the files stddef.h and stdarg.h (maybe others) which
> > are pretty much pointers to the next file with the same name,
> > I have posted at the STLport forums about the issue here:
> >
> > http://www.stlport.com/dcforum/DCForumID7/2130.html#4
> >
> > And I though you may want to know about this, should it be considered
> > a bug? In the meantime I am just renaming the files so they don't get
> > in the way.
>
>
>Does attached patch to mingw runtime headers  fix the problem?
>
>Danny
> >
> > Cheers!
> >
> >
> >
> > Rodrigo Hernandez, lonewolf programmer
> > Aeon Games
> > http://www.aeongames.com
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Sybase ASE Linux Express Edition - download now for FREE
> > LinuxWorld Reader's Choice Award Winner for best database on Linux.
> > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> > _______________________________________________
> > MinGW-users mailing list
> > Min...@li...
> >
> > You may change your MinGW Account Options or unsubscribe at:
> > https://lists.sourceforge.net/lists/listinfo/mingw-users

Rodrigo Hernandez, lonewolf programmer
Aeon Games
http://www.aeongames.com 

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

You means the COM DLL could only access by COM mechanism one method ?


______________________________________________________________________
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

Is there a good reason why the cpp library header files (without .h) do 
not #include <_mingw.h> (or equivalent of)?

For example why should I not expect the following to compile

#include <limits>

#ifndef __int64
     #error should be defined
     // works with <limits.h>
#endif


I want the definition of __int64 and other MS extensions but don't 
really what to change code to explicitly include _mingw.h or define myself.

SteveLee

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

I detect a little confusion here. Are you trying to create an import library
given only the existing DLL so that you can link to the functions in the DLL
using gcc?

If so then the results you see are correct as a COM DLL is a DLL that implements
an in-process server. That means that the functions in the Server DLL are accessed
using the runtime facilities provided by COM and NOT linked by a linker. You
call various COM functions that use the functions you found to find and call
the functionality exposed by the server DLL.

In other words it ain't gonna work, you need to use COM to access the functions
in the DLL.

Tools do exist that can query the server DLL and create stub code that you CAN
link to call the functions via COM.  In MSVC the easiest way is the #import
compiler extension. I don't know if MinGW or gcc provide any such tools - anyone
else know?

Altenatively Windows scripting languages provide easy access to some COM servers
(those that provide automation interfaces). Python provides access via Mark
Hammond's win32all extensions which are almost transparent in use.

SteveLee

______________________________________________________________________
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=2829505
By: infidel

Ah, I think I may have seen this error and fixed it locally and then forgotten
to report it. IIRC it was caused by the first line of aclocal being:

#!/usr/local/bin/perl

instead of #!/bin/perl


______________________________________________________________________
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=2829388
By: neilyu

I hold a COM DLL files, I wanne convert it to *.a file, but I can't EXPORTS
the functions in such DLL, It only show
        ordinal hint RVA      name
        1    0 000022F2 DllCanUnloadNow
        2    1 000022C6 DllGetClassObject
        3    2 000022DC DllRegisterServer
        4    3 000022B0 DllUnregisterServer


______________________________________________________________________
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=2829349
By: yottameter

I'm seeing a dir separator issue, I've tried to set DIR_SEPARATOR with no luck.
Specifically, I'm installing Qt, and if I do it using the installer included
with Qt, or do it manually, I get the same error. When I get to the make portion,
it looks like it's taking

/dir1/dir2/dir3/file.txt

in the Makefile and erroring out looking for

dir1dir2dir3file.txt

In previous posts, I saw an Ada example that was close, but I tried to
set DIR_SEPARATOR as an env var with no difference. Am I setting it correctly?
I tried to add escape slashes in the Makefile, but that didn't help either.
I'm new to mingw, but have used unix and linux. I'm using Mingw 3.1.0-1. I'm
using make 3.80.0-3.

Appreciate your time.

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

Sounds it does. So I am allowed to develop commercial software. That's terrific.

______________________________________________________________________
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=2829024
By: padcom13

I think this part of GPL FAQ covers the question completely:

"Can I use GPL-covered editors such as GNU Emacs to develop non-free programs?
Can I use GPL-covered tools such as GCC to compile them?
Yes, because the copyright on the editors and tools does not cover the code
you write. Using them does not place any restrictions, legally, on the license
you use for your code.
Some programs copy parts of themselves into the output for technical reasons--for
example, Bison copies a standard parser program into its output file. In such
cases, the copied text in the output is covered by the same license that covers
it in the source code. Meanwhile, the part of the output which is derived from
the program's input inherits the copyright status of the input.

As it happens, Bison can also be used to develop non-free programs. This is
because we decided to explicitly permit the use of the Bison standard parser
program in Bison output files without restriction. We made the decision because
there were other tools comparable to Bison which already permitted use for non-free
programs. "

______________________________________________________________________
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

Check out the MinGWiki for info on building a MinGW cross-compiler on Linux:

http://www.mingw.org/MinGWiki/index.php/build%20a%20Win32%20x-compiler%20for%20Linux

Igor

Neil Zanella wrote:

>Hello,
>
>I have taken a look at Section 11 of the Autoconf manual that comes
>with the autoconf
>GNU package. There it mentions that configure scripts produced with
>GNU autoconf can
>be created in such a way that it is possible to specify a special
>--target flag. Such a flag
>defines a script variable target_alias which may be used in configure
>scripts. When not
>specified the AC_CANONICAL_TARGET may be used to set the target based on the
>output of config.guess.
>
>OK, so far so good, but does all of this mean that from on my Fedora
>Core 2 Linux
>system I can write a configure script which can take an argument
>allowing me to make
>a call to the compiler and build a .exe file for Win32?
>
>Wouldn't I need a special compiler to do this? Does gcc come with
>cross compilation
>support? IMHO it would be quite nice to be able to build a .exe file
>from my Linux platform
>without having to reboot into windows and use cygwin or VC++. But how
>can I do this?
>
>AFAIK, Fedora Core 2 doesn't even ship gcc with cross compilation support,
>or does it? I've just never seen it done before.
>
>I wonder whether someone could help me sort out this issue, as I am somewhat new
>to autoconf and cross-compilation (two separate issues indeed, but it
>would be nice to
>be able to make them work in concert, so with one configure script I
>can build both my
>Linux executables, as well as my windows executables.
>
>Thanks!
>
>Neil
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>_______________________________________________
>MinGW-users mailing list
>Min...@li...
>
>You may change your MinGW Account Options or unsubscribe at:
>https://lists.sourceforge.net/lists/listinfo/mingw-users
>
>  
>

Hello,

I have taken a look at Section 11 of the Autoconf manual that comes
with the autoconf
GNU package. There it mentions that configure scripts produced with
GNU autoconf can
be created in such a way that it is possible to specify a special
--target flag. Such a flag
defines a script variable target_alias which may be used in configure
scripts. When not
specified the AC_CANONICAL_TARGET may be used to set the target based on the
output of config.guess.

OK, so far so good, but does all of this mean that from on my Fedora
Core 2 Linux
system I can write a configure script which can take an argument
allowing me to make
a call to the compiler and build a .exe file for Win32?

Wouldn't I need a special compiler to do this? Does gcc come with
cross compilation
support? IMHO it would be quite nice to be able to build a .exe file
from my Linux platform
without having to reboot into windows and use cygwin or VC++. But how
can I do this?

AFAIK, Fedora Core 2 doesn't even ship gcc with cross compilation support,
or does it? I've just never seen it done before.

I wonder whether someone could help me sort out this issue, as I am somewhat new
to autoconf and cross-compilation (two separate issues indeed, but it
would be nice to
be able to make them work in concert, so with one configure script I
can build both my
Linux executables, as well as my windows executables.

Thanks!

Neil

Posted on DATE by AUTHOR Hendrik Sattler
> Am Freitag, 29. Oktober 2004 16:04 schrieb Michael Gerdau:
> [...]
>
> Are answers in this mailing list forwarded to the forum at sf.net?
>

I wish.  No they are not.

Earnie

Am Freitag, 29. Oktober 2004 16:31 schrieb Anand, Vaidyanathan R:
> One possiblle problem with your Makefile entries could be the space in
> the path name for the MinGW location. Try replacing it with the short
> DOS (8.3) equivalent, as follows (also replacing the backslashes with
> forward slashes, although that might not be a problem).
>
> MINGW_HOME =3D "C:/Progra~1/MinGW"

If that's the case, it should be fixed...

HS

=2D-=20
Mein GPG-Key ist auf meiner Homepage verf=FCgbar: http://www.hendrik-sattle=
r.de
        oder =FCber pgp.net

PingoS - Linux-User helfen Schulen: http://www.pingos.org

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

I went to the folder that contains configure.ini and then type

autoconf

That's all I do, and I get 2 identical lines of error as I showed above.

Specifically, I want to compile GtkCairo, a Gtk widget that can draw vector
graphics. Its website is at

http://cairographics.org/cairo/GtkCairo

and its documentation for installation is at

http://cvs.cairographics.org/gtkcairo/Attic/INSTALL?view=markup

It doesn't have a premade binary so I have to compile from the source according
to the instruction in the installation documentation. After I extract the compressed
file, it creates a folder called "gtkCairo", which I then put into c:\msys.
The configure.in is then in /gtkcairo and its source fiiles (.h and .c) are
in /gtkcairo/gtkcairo.

After I downloaded autoconfi and automake with your direction, and if I simply
type "autoconf" anywhere in msys, it will run but says "no input file", so I
know autoconf works, but when there's actually an input file autocnof says it
can't find usr/bin/autom4te, which is actually in the /bin folder.

That is what my main problem is.

______________________________________________________________________
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

Am Freitag, 29. Oktober 2004 16:04 schrieb Michael Gerdau:
[...]

Are answers in this mailing list forwarded to the forum at sf.net?

HS

=2D-=20
Mein GPG-Key ist auf meiner Homepage verf=FCgbar: http://www.hendrik-sattle=
r.de
        oder =FCber pgp.net

PingoS - Linux-User helfen Schulen: http://www.pingos.org