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

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> -----Original Message-----
> From: min...@li...
> [mailto:min...@li...]On Behalf Of Victor
> Munoz
> Sent: Sunday, March 31, 2002 12:34 AM
> To: min...@li...
> Subject: [Mingw-users] no need for #include <stdio.h> ???
> 
> 
> gcc -o Hello Hello.c

Try enabling warnings:
gcc -Wall -o Hello Hello.c

Regards
Chris

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPKZPBg6qxNNoghKpEQIZ7QCfdbDfTK/nUiXKu/q796kGMp3/KfgAoNrq
Y/EqSIWjRpoc9nYNAtKir2Ac
=fboH
-----END PGP SIGNATURE-----

Hi,

I just run this program

int main(int argc, char **argv) {
 printf ("\n\aHello\n");
 return (0);
}

then I compiled

gcc -o Hello Hello.c

and got the executable. It is working OK

The question is Why I dont need the #include <stdio.h> at the begining
of the program?

Is it a glitch?

Note: I check my environment and no indication of lib or any other path
to lib

and search for stdio.h in all directories and I found only located in
MinGW\include\stdio.h

Thanks,

Victor Munoz

On 3/29/2002 at 6:34 PM Jean le Roux wrote:

>
>The problem is, however, with libnetapi32.a. It's not being linked
>in. I use the same configure.in and Makefile.am for compiling my
>projects in RH Linux 7.1 and Windoze NT. Under Linux the link line
>will only need -lcrypto, under windows it needs -lcrypto and
>-lnetapi32, due to the extra use of nb30.h.
> 
>Now, as of yet I know no clean cut way (or even a dirty one) of
>splitting my Makefile.am and/or configure.in to do different things
>under windows and linux. I can't go add -lnetapi32 to my Makefile.am's
>isep_config_LDADD =  -lcrypto .. this would cause the linux build to
>complain. 
>
>Does anyone know how to test for windows and split functionality in a
>Makefile.am ?
>

See the autoconf documentation for AC_CHECK_FUNC.  If you can't decipher
it's contents then ask on aut...@gn....

Earnie.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Hi folks,

	Just throwing in my tuppence.

	Before I go on, let me remind everyone, this mailing list is not for dealing with MSYS based problems.  MSYS 
is not Mingw, but it can use the Mingw development tools.  In other words, MSYS can "use" Mingw or any gcc that 
the developer might have a notion to use, it is not Mingw.  Mingw, out of the distro box, does not support automake or 
./config.  Nor was it ever designed to use automake or ./config.  Mingw is designed to be used through either 
cmd.exe or command.exe (DOS Console under Win32).  MSYS provides a unix-like shell, which allows the 
developer to build using automake and/or ./config processing through an rxvt interface.

	If you have any questions about MSYS, then those should be directed to the mingw-msys m/l.  Not this one.

	Besides, you are more likely to get a valid and authoratative response to these sorts of questions if you post 
them to the appropriate mailing list (min...@li...) then you are if you post such questions to 
the mingw-users list.

On 29 Mar 2002 at 18:34, Jean le Roux wrote:

> I solved the problem, but in a roundabout way.
> 
> Here's what I did, please suggest better aproaches if you have any.
> 
> > When I compile I get:
> > 
> > makefile:165: warning: overriding commands for target `.s.o'
> > makefile:162: warning: ignoring old commands for target `.s.o'
> > makefile:182: warning: overriding commands for target `.s.lo'
> > makefile:179: warning: ignoring old commands for target `.s.lo' c++
> > -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c main.cc c++
> > -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c common.cc /bin/sh
> > ../libtool --mode=link c++  -g -O2  -o isep-config.exe  main.o
> > common.o -lcrypto  ../libtool: cygpath: command not found c++ -g -O2
> > -o isep-config.exe main.o common.o  -lcrypto common.o: In function
> > `verify_own_mac(mac_t)':
> > //e/projects/multicast/isep/confsrc/common.cc:334: undefined
> > reference to `Netbios@4' common.o: In function `get_own_mac(mac_t &,
> > int)': //e/projects/multicast/isep/confsrc/common.cc:364: undefined
> > reference to `Netbios@4'
> > //e/projects/multicast/isep/confsrc/common.cc:393: undefined
> > reference to `Netbios@4' make: *** [isep-config.exe] Error 1
> > 
> > I include windows.h. I saw it includes nb30.h, but for surety's sake
> > I included nb30.h explicitely aswell.
> 
> The problem is not with the include.. the compiler would have caught
> "implicite declaration" of Netbios() in such a case. I realised this
> after some reflection and considderation as to _where_ the compilation
> goes wrong.
> 
> The problem is, however, with libnetapi32.a. It's not being linked in.
> I use the same configure.in and Makefile.am for compiling my projects
> in RH Linux 7.1 and Windoze NT. Under Linux the link line will only
> need -lcrypto, under windows it needs -lcrypto and -lnetapi32, due to
> the extra use of nb30.h.
> 
> Now, as of yet I know no clean cut way (or even a dirty one) of
> splitting my Makefile.am and/or configure.in to do different things
> under windows and linux. I can't go add -lnetapi32 to my Makefile.am's
> isep_config_LDADD =  -lcrypto .. this would cause the linux build to
> complain. 
> 
> Does anyone know how to test for windows and split functionality in a
> Makefile.am ?

	Have you thought about asking, somewhere in your make process, which OS you are actually building for?  
Mingw knows.  Linux probably has no way to truly know unless you want to play with cross-compiling.  It is appearing 
that you are dangerously close to cross-compiling problems (which really are not the focus of this mailing list except 
where existing cross-compiling hybrids, which use Mingw, are concerned.  MSYS does not fall under this category.).

	MSYS is MSYS, I must restate.  MSYS has some oddities to it that can not be reproduced using the dos 
console under Win32 because MSYS actually invokes a "shell" which is neither cmd.com or command.com, even 
though the "shell" invoked is launched from a dos console.  That "shell" is not the command console (win95 or other 
Windows).  The initiation of that shell is something you can fiddle with if you want, though I wouldn't suggest it unless 
you are ready for lots of headaches.

	Finally, take a look at the system variables you have available for the platform you are building for.  Some of 
those system variables tell make scripts which OS is actually running.  To cut another cookie, automake and (g)make 
are not the same thing.


	Paul G.

I cannot know if anyone is still interested in this topic, but it's
friday and I feel a holiday coming on and feel in the mood to expound
out of compassion for others (nothing to with Easter necessarily, I am
not a Xian but trying to be a Buddhist...). So here goes again...

On Fri, 22 Mar 2002 11:34:50 -0600 (CST), "M Joshua Ryan"
<jo...@um...> said:
> On Fri, 22 Mar 2002, Soren Andersen wrote:
>
> > On Fri, 22 Mar 2002 09:33:15 -0600 (CST), "M Joshua Ryan"
> > <jo...@um...> said:
> >
> > > then you probably need to look at CreatePipe, DuplicateHandle,
> > > and CreateProcess in win32. for cygwin, you can stick with
> > > pipe(2).
> >
> > Thanks, Joshua, but there's still some kind of breakdown in
> > comprehension here. I think it might stem from lack of familiarity
> > with UNI*-style tool pipelining, in shell scripts, on your end? In
> > what i am doing here, the *SHELL* is going to be creating a pipe
> > (sometimes, according to user decree, NOT programmer choice!!) and
> > supplying all the context for what's going on here. This is a
> > cross-platform stand-alone console application, not a Win32-only
> > complex something-or-other. The real crux of my initial query lies
> > in that porting applications to Windows from standard UNI* -style
> > code is complexified because you cannot treat stdin and stdout on
> > Win32 like any other filehandle, as in the UNI* credo "everything
> > is a file".

> as i understand it, normal windows batchfiles cannot create pipes.
> it's part of their inheritance from DOS. i don't think there's a
> terrible lack of understanding on my part.


> unix shells create pipes between programs using the pipe(2) system
> call to setup the proper connections between filehandles before
> calling fork(2). since DOS didn't have a fork() (because it didn't
> have multiple processes), the command shell implemented "piping" by
> redirecting the output of the first program to a temporary file,
> running it to completion, and then redirecting the input of the
> second program to the temporary file.


-- 
The makefiles which eventually result from using 'automake' 1.5x are monstrosities. Sheer hellish madness. Several dozen targets, named obscene things like "am_remake_your_mother"; utterly counter-intuitive, buried in 4 or 5 levels of indirection, swamped in a thousand lines of baffling, migraine-inducing auto-generated superfluity. [These] Makefiles  ought to be taken out and bled to death slowly, shot, burned, staked through the heart, generally Buffy-ated to the maximum possible extent.
    -- Soren Andersen (me) in
<http://groups.google.com/groups?selm=Xns91D2A2408EF9Dsorenngrp89%4064.8.1.226>

> > I found another problem with gcc 2.95.3-6.
> > In c:\gcc\include\winbase.h, someone modified the
> > structure to have a name
> > _ANONYMOUS_UNION and _ANONYMOUS_STRUCT preceding
> > which contains wProcessorArchitecture.
> > Also other similar changes were made.
> >
>
> I think the quickest way to fix your problem may be to simply include
> windows.h  before winbase.h.  That will define those macros.  Perhaps the
> defines you mention don't really belong in windows.h but in windef.h.  Any
> patch you care to submit will be reviewed.
>
> Danny

Isn't winbase.h one of a group of files that you are _never_ supposed to include
itself? Just include windows.h, and let it do the rest?

Max.

I cannot know if anyone is still interested in this topic, but it's
friday and I feel a holiday coming on and feel in the mood to expound
out of compassion for others (nothing to with Easter necessarily, I am
not a Xian but trying to be a Buddhist...). So here goes again...

On Fri, 22 Mar 2002 11:34:50 -0600 (CST), "M Joshua Ryan"
<jo...@um...> said:
> On Fri, 22 Mar 2002, Soren Andersen wrote:
>
> > On Fri, 22 Mar 2002 09:33:15 -0600 (CST), "M Joshua Ryan"
> > <jo...@um...> said:
> >
> > > then you probably need to look at CreatePipe, DuplicateHandle,
> > > and CreateProcess in win32. for cygwin, you can stick with
> > > pipe(2).
> >
> > Thanks, Joshua, but there's still some kind of breakdown in
> > comprehension here. I think it might stem from lack of familiarity
> > with UNI*-style tool pipelining, in shell scripts, on your end? In
> > what i am doing here, the *SHELL* is going to be creating a pipe
> > (sometimes, according to user decree, NOT programmer choice!!) and
> > supplying all the context for what's going on here. This is a
> > cross-platform stand-alone console application, not a Win32-only
> > complex something-or-other. The real crux of my initial query lies
> > in that porting applications to Windows from standard UNI* -style
> > code is complexified because you cannot treat stdin and stdout on
> > Win32 like any other filehandle, as in the UNI* credo "everything
> > is a file".

> as i understand it, normal windows batchfiles cannot create pipes.
> it's part of their inheritance from DOS. i don't think there's a
> terrible lack of understanding on my part.

Put none too diplomatically, but honestly (and with kind intention): there actually *is* clearly now a really fundamental misbelief on your part and depending on what (kind of programming) you get involved with it will surely bite you someday in the future, sooner or later.

Put in psuedocode-ish terse style:
-------------------------------------------------------
   DOS  !=  Win32  [ != UNIX-ported-to-Windows]
-------------------------------------------------------
Put at somewhat greater verbosity:

MinGW is really three things from a programming-strategy POV, you could say. First off the run-time basis for the C library calls is MSVCRT.DLL, Microsoft's implementation of a "standard" ANSI C library which is none too standard and conforming, but is what we have to work with.

Secondly as users will note when they download MinGW, a sizeable bundle of files gets installed which consists of what's called "win32api." This is libraries (lib*.a in our case but for users of MSVC they'd be *.lib) and their accompanying header files. Things like "libkernel32.a" and "libgdi.a". This is the Win32 API: what Microsoft gives the world to let programs interact with their many OS's (Let's see, there's 'Win32s' running under 16-bit Win3.x; and "Win9x/Millenium", and "WinNT3.x-WinNT4/Win2K/WinXP. These are all DIFFERENT  and specifically [in specific instances] INCOMPATIBLE operating system platforms). "Win32" attempts -- but none too well or cleanly (read David Korn) -- to implement a "uniform" interface to these several different flavors of 'doze and in typical M$ fashion, 'the devil is in the details.'

Thirdly there is a 'port' of "libiberty.a" which is a Gnu project library that adds many useful functions (implemented in C) considered standard and desirable on a modern feature-rich *NIX-like OS (LINUX, *BSD's) but often missing on many other flavors of OS.

Other people might see things from a different perspective or think of something important to add or subtract, but as a start on clarifying this, this is how it is 'according to Soren'.

These three things are really separate, especially the 2cd item from the first or the third ones. The Win32API is completely separate from and different from a standard or 'extended-standard' C library.

The one thing MinGW is NOT is a _DOS_ development platform. That already exists and has existed for a   *l  o  n  g*   time now, and it's called "DJGPP". It could be said to be ancestrally related to MinGW and everyone using any GNU software ported to Windows today owes a big debt of gratitude to D.J. Delorie for his pioneering work on DJGPP. But it's a completely separate thing, because, (yep, let's repeat it once again people):
---------------------
  DOS  !=  Win32
---------------------

> unix shells create pipes between programs using the pipe(2) system
> call to setup the proper connections between filehandles before
> calling fork(2). since DOS didn't have a fork() (because it didn't
> have multiple processes), the command shell implemented "piping" by
> redirecting the output of the first program to a temporary file,
> running it to completion, and then redirecting the input of the
> second program to the temporary file.

Yes, this is quite true. Also largely only of historical, trivial interest because most people do not run DOS anymore. Win32 != DOS. Unfortunately even the folks at Microsoft have apparently long been in the habit of themselves sometimes referring to a "DOS box" running "under Windows" and therefore have compounded the apparently widespread confusion concerning this. Since I don't work and never have worked for M$ this is in no way my responsibility.

To answer your first statement above specifically: Windows 32-bit uses Real Pipes. Even more specifically WinNT and decendants use Real Pipes and Real 'alot else' -- NT in console mode is *almost* a *NIX OS (and yes there is even a way [expensively] to implement a thing that's almost as good as a true *NIX `fork' on Win32). Even more to the point (increasing verbosity yet more but getting back to the thrust of my original questions about your meaning): when discussing Windows _shell_ scripting one *must* specify *which shell* one is referring to. NT's CMD.exe is a completely different and far more competent creature than Win9x's command.com (which running under Windows9x in a so-called "DOS box" may or may not be subject to all or some of the DOS limitations you've referred to: it's a matter for more research than I am able to do at this time and I am going to limit my statements here to what I can authoritatively speak on).

In ANY event the correct way to refer to the kind of program the o.p. was talking about (that was me) is **Win32 Console Mode**. Any competent book on Windows (esp. on NT or decendants) will refer to this. I'm going to suggest a suitably concise new coinage for the Internet and now nickname "Win32 Console Mode" as "win32c-m". "win32c-m" has its own API and everything (and that API looks really nothing like DOS and nothing like standard *NIX I/O and really nothing like anything else that's ever been).

I heartily recommend to readers of this List that they find a book: _Programming Win32 Under the API_ by Pat Villani [CMP, 2001, ISBN 1-57820-067-9] which among other things will dispel the pervasive badness of the 'little bit of knowledge' that a lot of people seem to display about Windows and Win32. It even includes a version (albeit outdated of course) of MinGW on CD-ROM! Of course this book covers both win3gui and win32c-m. And I don't know the author and have no fiduciary interest in the book.

Finally I'd like to remind readers, especially some of the recent contributors to this thread, that one ought to go back and read a thread from the beginning. Mostly the original context and point of this thread (I was the o.p.) was lost almost immediately after the second generation of reply had been posted. Leading me to suspect that most of those who replied are young and inexperienced at List-mode discussion.

    Thanks for reading,
       Soren Andersen



-- 
The makefiles which eventually result from using 'automake' 1.5x are monstrosities. Sheer hellish madness. Several dozen targets, named obscene things like "am_remake_your_mother"; utterly counter-intuitive, buried in 4 or 5 levels of indirection, swamped in a thousand lines of baffling, migraine-inducing auto-generated superfluity. [These] Makefiles  ought to be taken out and bled to death slowly, shot, burned, staked through the heart, generally Buffy-ated to the maximum possible extent.
    -- Soren Andersen (me) in
<http://groups.google.com/groups?selm=Xns91D2A2408EF9Dsorenngrp89%4064.8.1.226>

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> -----Original Message-----
> From: min...@li...
> [mailto:min...@li...]On Behalf Of 
> Danny Smith
> Sent: Friday, March 29, 2002 12:55 AM
> To: Sternbach, William [IT]; 'min...@li...'
> Subject: Re: [Mingw-users] Another bug in gcc 2.95.3-6.
> 
> I think the quickest way to fix your problem may be to simply
> include windows.h  before winbase.h.  That will define those
> macros.  
> Perhaps the
> defines you mention don't really belong in windows.h but in 
> windef.h.  Any
> patch you care to submit will be reviewed.

According to Charles Petzold's book "Programming Windows" 'windows.h'
should always be included before any other header files.

Regards
Chris

P.S. Sorry, Danny! I was only going to post this on the list, not to
your private mailbox.

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPKSpAg6qxNNoghKpEQIs2QCg2E6u6l38XzIA9w+BHsY7M5QIIq0AoNbS
8QJ+Lqr3iiADC1EAPh4sTWJM
=ppUu
-----END PGP SIGNATURE-----

I solved the problem, but in a roundabout way.

Here's what I did, please suggest better aproaches if you have any.

> When I compile I get:
> 
> makefile:165: warning: overriding commands for target `.s.o'
> makefile:162: warning: ignoring old commands for target `.s.o'
> makefile:182: warning: overriding commands for target `.s.lo'
> makefile:179: warning: ignoring old commands for target `.s.lo'
> c++ -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c main.cc
> c++ -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c common.cc
> /bin/sh ../libtool --mode=link c++  -g -O2  -o isep-config.exe  main.o common.o -lcrypto  
> ../libtool: cygpath: command not found
> c++ -g -O2 -o isep-config.exe main.o common.o  -lcrypto
> common.o: In function `verify_own_mac(mac_t)':
> //e/projects/multicast/isep/confsrc/common.cc:334: undefined reference to `Netbios@4'
> common.o: In function `get_own_mac(mac_t &, int)':
> //e/projects/multicast/isep/confsrc/common.cc:364: undefined reference to `Netbios@4'
> //e/projects/multicast/isep/confsrc/common.cc:393: undefined reference to `Netbios@4'
> make: *** [isep-config.exe] Error 1
> 
> I include windows.h. I saw it includes nb30.h, but for surety's sake
> I included nb30.h explicitely aswell.

The problem is not with the include.. the compiler would have caught
"implicite declaration" of Netbios() in such a case. I realised this
after some reflection and considderation as to _where_ the
compilation goes wrong.

The problem is, however, with libnetapi32.a. It's not being linked
in. I use the same configure.in and Makefile.am for compiling my
projects in RH Linux 7.1 and Windoze NT. Under Linux the link line
will only need -lcrypto, under windows it needs -lcrypto and
-lnetapi32, due to the extra use of nb30.h.
 
Now, as of yet I know no clean cut way (or even a dirty one) of
splitting my Makefile.am and/or configure.in to do different things
under windows and linux. I can't go add -lnetapi32 to my Makefile.am's
isep_config_LDADD =  -lcrypto .. this would cause the linux build to
complain. 

Does anyone know how to test for windows and split functionality in a
Makefile.am ?

bye
-- 
Jean le Roux
Binary Entropy Catalyst

Hi all

I've gone the netbios route for gathering hardware addresses off my
interfaces. Unfortunately netbios is not a happy camper :(

When I compile I get:

makefile:165: warning: overriding commands for target `.s.o'
makefile:162: warning: ignoring old commands for target `.s.o'
makefile:182: warning: overriding commands for target `.s.lo'
makefile:179: warning: ignoring old commands for target `.s.lo'
c++ -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c main.cc
c++ -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c common.cc
/bin/sh ../libtool --mode=link c++  -g -O2  -o isep-config.exe  main.o common.o -lcrypto  
../libtool: cygpath: command not found
c++ -g -O2 -o isep-config.exe main.o common.o  -lcrypto
common.o: In function `verify_own_mac(mac_t)':
//e/projects/multicast/isep/confsrc/common.cc:334: undefined reference to `Netbios@4'
common.o: In function `get_own_mac(mac_t &, int)':
//e/projects/multicast/isep/confsrc/common.cc:364: undefined reference to `Netbios@4'
//e/projects/multicast/isep/confsrc/common.cc:393: undefined reference to `Netbios@4'
make: *** [isep-config.exe] Error 1

I include windows.h. I saw it includes nb30.h, but for surety's sake
I included nb30.h explicitely aswell.

nb30.h _does_ declare Netbios(PNCB), right at the end.
My offending call looks like:

328    LANA_ENUM AdapterList;
329    NCB Ncb;
330    memset(&Ncb, 0, sizeof(NCB));
331    Ncb.ncb_command = NCBENUM;
332    Ncb.ncb_buffer = reinterpret_cast<unsigned char*>(&AdapterList);
333    Ncb.ncb_length = sizeof(AdapterList);
334    Netbios(&Ncb);

Has anyone encountered this before, or am I straying from the path
somewhere ?

thnx
-- 
Jean le Roux
Binary Entropy Catalyst

This sort of thing should not be posted here on the mingw-users list.  If you have bug reports re: MSYS, submit them 
via the bug reports page after first mentioning them at the MSYS mailing list

	mailto:  msy...@li...

	MSYS distro does not include a compiler.  That is something which is added after you have installed the files 
downloaded from the latest MSYS distro.

On 28 Mar 2002 at 8:22, Sternbach, William [IT] wrote:

> Hello,
> 
> I've encountered what I believe is a bug with the
> MSYS 1.1 gcc compiler version 2.95.3.6.
> 
> gcc does not process wildcards correctly:
> 
> gcc -c mapm*.c

	Afaik, mingw does not support wildcards in a compile line.  You need to create a makefile, under Mingw, to 
support multiple .c source code files.  Either that, or put all of your .c source code files on the command line

	(eg.  gcc foo.c, foo2.c, foo3.c -c foo.o)

	For multiple source code files, the foo.o is required, otherwise, afaik, gcc will generate foo.o, foo2.o and 
foo3.o.

> 
> The above line should compile the programs which
> begin with mapm and have the ".c" suffix.
> (Example: mapmadd.c, mapm_cpi.c, mapm_div.c, etc)

	Again, consider a make file.

	Paul G.

 --- "Sternbach, William [IT]" <wil...@ss...> wrote: > Hello,
> 
> I found another problem with gcc 2.95.3-6.
> In c:\gcc\include\winbase.h, someone modified the
> structure to have a name
> _ANONYMOUS_UNION and _ANONYMOUS_STRUCT preceding
> which contains wProcessorArchitecture.
> Also other similar changes were made.
>

I think the quickest way to fix your problem may be to simply include
windows.h  before winbase.h.  That will define those macros.  Perhaps the
defines you mention don't really belong in windows.h but in windef.h.  Any
patch you care to submit will be reviewed.
 
Danny

> _______________________________________________
> MinGW-users mailing list
> Min...@li...
> 
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users 

http://www.sold.com.au - SOLD.com.au Auctions
- 1,000s of Bargains!

 --- Jeff Baker <jb...@qn...> wrote: > Here's my problem.  I have a
bunch of (static) libs I've built with gcc
> using mingw under QNX6 (I built my own mingw gcc for this).  Now I want
> to statically link these libs with a project that I'm building in MS
> Visual C++ 6.0.  The problem is that I get an 'Unable to resolve
> external symbol' error for '__alloca' for each lib.  Is there some magic
> I need to do while building gcc or can I solve the problem somehow in my
> MSVC project?
> 
>

One trick that work for me in the past with a similar problem with a
non-GCC Fortran compiler was to go into /lib/gcc-lib/mingw32/2.95.3-6
(where libgcc.a lives), extract _chstk.o  from libgcc.a  using:

ar -x libgcc.a _chkstk.o

and then put that _chkstk.o into your project.

Danny


> _______________________________________________
> MinGW-users mailing list
> Min...@li...
> 
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users 

http://www.sold.com.au - SOLD.com.au Auctions
- 1,000s of Bargains!

Here's my problem.  I have a bunch of (static) libs I've built with gcc
using mingw under QNX6 (I built my own mingw gcc for this).  Now I want
to statically link these libs with a project that I'm building in MS
Visual C++ 6.0.  The problem is that I get an 'Unable to resolve
external symbol' error for '__alloca' for each lib.  Is there some magic
I need to do while building gcc or can I solve the problem somehow in my
MSVC project?

Hello,

I found another problem with gcc 2.95.3-6.

gcc 2.95.2 can compile the extremely large and complex
Larry Wall Perl interpreter (which is written in "C").
You download the "C" source code and you build it using
gcc.

But, with our "new" gcc 2.95.3-6 compiler, it doesn't compile.
I spent alot of time to figure out why.
Someone (making a patch to the gcc after version 2.95.2,
decided to change the c:\gcc\include\winbase.h and other
header files.  

In c:\gcc\include\winbase.h, someone modified the
structure to have a name
_ANONYMOUS_UNION and _ANONYMOUS_STRUCT preceding
which contains wProcessorArchitecture.
Also other similar changes were made.

Now, Perl (which is one of the most used language used to process
data from web pages on the internet) can no longer be compiled
with the gcc 2.95.3 compiler.
Every other Microsoft, Borland, Watcom, Sun, and gcc on Sun
can compile the "C" source code of the "Perl Interpreter".
The only people who cannot are the people who use gcc 2.95.3-6.

As a result, I have been forced to go back to using the
gcc 2.95.2 compiler.

If someone would be willing to fix the 2.95.3-6 compiler,
it would be great.  I hope the new gcc version 3 compiler will not
inherit have these bad header files from 2.95.3-6 compiler.

I have a question:

If I go back to using the gcc 2.95.2 compiler,
is there any serious bugs I should be aware of?

I'm sure the 2.95.3-6 compiler contains bug fixes,
but I'm not sure where to look to find a history of the
bug fixes.

Thanks in advance for your Email reply.

- Bill

 --- Jean le Roux <je...@in...> wrote: > Hi all
> 
> I notice that stdio.h does not declare an snprintf() function
> under mingw. It does however provide all the other "expected" tools
> such as:
> 
> int printf(const char *format, ...);
> int fprintf(FILE *stream, const char *format, ...);
> int sprintf(char *str, const char *format, ...);
> //not present under mingw: int snprintf(char *str, size_t size, const
> char *format, ...);
> 
> There is however an _snprintf() declared. From what I can tell
> it's interchangeable with the normal snprintf().
> 
> It looks like:
> int _snprintf(char *str, size_t size, const char *format, ...);
> 
> How do you guys go about catering for snprintf calls? Would a macro
> in the source file suffice ? 
> 
> eg
> #ifdef __MINGW32__
> #define snprintf _snprintf
> #endif
> 

That will work as a local fix, but I am hesitant to put that in stdio.h
header just yet.

Until C99, snprintf was not part of standard.  I am actually working on
putting all the _foo functions from msvcrt.dll that are not oldnames but
are C99 names into headers and also (as stub functions) into libs.  One
reason for putting them into lib, is that many configure scripts do two
tests: One to check for declaration, another (providing a minimal
declaration in source and not including header) to check if function is in
lib.

In C++, defines like that can cause problems with namespaces (eg,
::snprintf), and G+ headers actually undefine C runtime function macro 
versions.

Danny

http://www.sold.com.au - SOLD.com.au Auctions
- 1,000s of Bargains!

Hallo,

Since one year I have not used MinGW, because I change
The deparment in the University. Now I installed again
MinGw on my Workstation. 

I was really surprised, how easy it was to install MinGW
Now. One year ago it was a very complicated thing.

My thanks to all devellopers.

Georg Fuss | Techn. Universit"at Berlin
Phone: Office +49 30 314 79 866 Home +49 30 815 30 32
Homepage: http://math.tu-berlin.de/~fuss

Jean le Roux <je...@in...> writes:

> Hi
> 
> Perhaps the subject line should rather read "Lack of..."
> 
> I have code I'm porting from Linux to NT. Under linux I get the mac
> of a PCI card, by opening a socket and doing some ioctl stuff to the
> fd. How will I go about getting a mac of a card under Win32? I see
> Mingw32 does not have ioctl. 
> 
> Does anyone out there have an example snip of how mac's are beaten
> out of windows ?

Use SendARP(). Its found in iphlpapi.dll, I think. You may need to
upgrade your w32api, as this function was added rather recently.

-- 
/Jesper

Hello,

I've encountered what I believe is a bug with the
MSYS 1.1 gcc compiler version 2.95.3.6.

gcc does not process wildcards correctly:

gcc -c mapm*.c

The above line should compile the programs which
begin with mapm and have the ".c" suffix.
(Example: mapmadd.c, mapm_cpi.c, mapm_div.c, etc)

It does seem to attempt to compile each program separately,
but it gives you hundreds of compiler errors when the code
should compile perfectly.

But, it works if you code each program on a separate line like:
gcc -c mapmadd.c
gcc -c mapm_cpi.c
gcc -c mapm_div.c

I ran into this bug when attempting to compile a wonderful set
of "C" programs from Michael Ring which do arbitrary precision
math.  I used his bat file which contained gcc -c mapm*.c and
I ran into this problem.

This "gcc -c mapm*.c" syntax works on all other compilers, including:
1) Unix gcc compiler,
2) gcc port for the Microsoft windows created by D.J. Delorie
   and available at www.delorie.com/djgpp
3) All Microsoft and Borland compilers.
4) Sun Microsystems's compiler.

If anyone wishes to make a patch for this, it would be helpful
in making our mingw version 2.95.3.6 compiler able to compile
software and build software you download from the internet
successfully like other compilers.

- Bill

Hi

Perhaps the subject line should rather read "Lack of..."

I have code I'm porting from Linux to NT. Under linux I get the mac
of a PCI card, by opening a socket and doing some ioctl stuff to the
fd. How will I go about getting a mac of a card under Win32? I see
Mingw32 does not have ioctl. 

Does anyone out there have an example snip of how mac's are beaten
out of windows ?

I have written a Delphi app that doe this once.. not nice, I had to
use winsocks etc.. I'm hoping there is a way that hurts less :)

thx
-- 
Jean le Roux
Binary Entropy Catalyst

Hi all

I notice that stdio.h does not declare an snprintf() function
under mingw. It does however provide all the other "expected" tools
such as:

int printf(const char *format, ...);
int fprintf(FILE *stream, const char *format, ...);
int sprintf(char *str, const char *format, ...);
//not present under mingw: int snprintf(char *str, size_t size, const char *format, ...);

There is however an _snprintf() declared. From what I can tell
it's interchangeable with the normal snprintf().

It looks like:
int _snprintf(char *str, size_t size, const char *format, ...);

How do you guys go about catering for snprintf calls? Would a macro
in the source file suffice ? 

eg
#ifdef __MINGW32__
#define snprintf _snprintf
#endif

thx
-- 
Jean le Roux
Binary Entropy Catalyst

In a message dated 27/3/02 8:34:47 pm, 
min...@li... writes:

>Is there any tip for compiling stlport with mingw? I have downloaded
>stlport but couldnt to compile it.

Hi Emre,
First, let me point out that I am no programmer. This is my first
major post to the group (I usually lurk), so sorry if this explanation
annoys any pros out there!

So Emre, at the risk of showing my ignorance, this is how I got STLport-4.5.3
to compile with Mingw32. My explanation goes on to show the include order and
a sample makfile for using STLport-4.5.3 with an SDL openGl app.
(I have used STLport successfully with fltk too).

Note that my development drive is E:

After reading the STLport-4.5.3 install file and following the instructions,
I made these changes...

I copied the files:

exception
new
new.h

from: E:\mingw32\lib\gcc-lib\mingw32\2.95.3-6\include
to: E:\mingw32\include\

In the file:
STLport-4.5.3/stlport/config/stl_gcc.h
I changed _STLP_NATIVE_INCLUDE_PATH and _STLP_NATIVE_CPP_RUNTIME_INCLUDE_PATH
Here is the appropriate section of code. My changes are marked Bogtoad

----------------------------------------------------
// gcc-2.95.0 used to use "g++-3" directory which has been changed to "g++" in
// system-dependent "include" for 2.95.2 except for Cygwin and Mingw packages.
// I expect "g++-3" not being used in later releases.
// If your installation use "g++-3" include directory for any reason 
(pre-2.95.2 or Win binary kit),
// please change the macro below to point to your directory.

// Bogtoad additions
// change _STLP_NATIVE_INCLUDE_PATH from ../g++-3 to E:/mingw32/include
#define BOGTOAD_STLP_NATIVE_INCLUDE_PATH E:/mingw32/include/g++-3

# if defined(__DJGPP)
#   define _STLP_NATIVE_INCLUDE_PATH ../lang/cxx
# elif (__GNUC__ >= 3) || (__GNUC_MINOR__ >= 97)
#   define _STLP_NATIVE_INCLUDE_PATH ../include/g++-v3
# elif ((__GNUC_MINOR__ >= 95 && __GNUC_MINOR__ < 97) && !( defined 
(__FreeBSD__) || defined (__NetBSD__) || defined(__sgi) ) )
#   define _STLP_NATIVE_INCLUDE_PATH BOGTOAD_STLP_NATIVE_INCLUDE_PATH
# elif (__GNUC_MINOR__ > 8) && (__GNUC_MINOR__ < 95) && (__GNUC__ < 3) && 
!defined( __Lynx__ )
// this really sucks, as GNUpro does not really identifies itself, so we have 
to guess 
// depending on a platform
#   ifdef __hpux
#    define _STLP_NATIVE_INCLUDE_PATH BOGTOAD_STLP_NATIVE_INCLUDE_PATH
#   else
#    define _STLP_NATIVE_INCLUDE_PATH ../g++-2
#   endif
# else
#   define _STLP_NATIVE_INCLUDE_PATH g++
# endif

// <exception> et al
// $$$BOGTOAD additions
// change _STLP_NATIVE_CPP_RUNTIME_INCLUDE_PATH from ../include to 
E:/mingw32/include/g++-3
#define BOGTOAD_STLP_NATIVE_CPP_RUNTIME_INCLUDE_PATH E:/mingw32/include // 
added Bogtoad

# ifdef __FreeBSD__
#   if (__GNUC__ > 2) || (__GNUC__ == 2 && __GNUC_MINOR__ > 95)
#     define _STLP_NATIVE_CPP_RUNTIME_INCLUDE_PATH 
BOGTOAD_STLP_NATIVE_CPP_RUNTIME_INCLUDE_PATH
#   endif
# else
// azov
#   ifdef __Lynx__ 
#     define _STLP_NATIVE_CPP_RUNTIME_INCLUDE_PATH _STLP_NATIVE_INCLUDE_PATH
#   else
#    if (__GNUC__ > 2) || (__GNUC__ == 2 && __GNUC_MINOR__ >= 97)
// #     define _STLP_NATIVE_CPP_RUNTIME_INCLUDE_PATH ../g++-v3
#   else
#     define _STLP_NATIVE_CPP_RUNTIME_INCLUDE_PATH 
BOGTOAD_STLP_NATIVE_CPP_RUNTIME_INCLUDE_PATH
#   endif
#  endif
# endif

#endif /* GNUC_MINOR < 8 */

# define _STLP_NATIVE_CPP_C_INCLUDE_PATH _STLP_NATIVE_INCLUDE_PATH
# define _STLP_NATIVE_C_INCLUDE_PATH 
BOGTOAD_STLP_NATIVE_CPP_RUNTIME_INCLUDE_PATH
----------------------------------------------------

NOTE, when running the regression test, start an MS-DS window and type bash.
Once bash is running, type this command: echo 'a string' | stl_test.exe > 
stl_test.out

Then compare the files stl_test.vc6.exp and stl_test.out with ExamDiff. There 
should be NO
differences in the files.

In all my projects I include the following prefix file (it gets included 
before
anything else:
----------------------------------------------------
/*****************************************************************************

******
  BogToadPrefix.h
        
*************************************
**********************************************/

#if ! defined (BOGTOADPREFIX_H)
#   define BOGTOADPREFIX_H

#   if ! defined (WIN32)
#      define WIN32
#   endif

#   define   _STLP_NO_OWN_IOSTREAMS 1

#   include <stl/_config.h>

//  other stuff here 

#endif // BOGTOADPREFIX_H
----------------------------------------------------
Finally, here is a sample Makefile, showing the include order (important!)
----------------------------------------------------
#
# MinGW makefile generated by MinIDE 0.9
#

.SUFFIXES: .exe .res .a .o .c .cpp .cc .cxx .m .rc .p .f .F .r .y .l .s .S 
.def .h

CC=g++
LD=g++
AR=ar
RC=windres
RES=
IMP=makelib
WIN32_FLAG=-mwindows
RSX32_FLAG=
DLL_FLAG=-mdll
CRT_FLAG=
NRT_FLAG=
SYS_FLAG=
SO_FLAG=
STRIP_FLAG=-s


all: lesson29.exe

CC_TARGET_01=$(WIN32_FLAG) $(MT_FLAG) 
CFLAGS_TARGET_01= -I/STLport-4.5.1/stlport  -I/SDL-1.2.3/include  -include 
BogToadPrefix.h -O2 -Wall -i686

lesson29.exe: ./obj/lesson29.o
    $(LD) $(CC_TARGET_01) -s  -L/SDL-1.2.3/lib -o lesson29.exe 
./obj/lesson29.o -lmingw32  -lSDLmain  -lSDL  -lopengl32  -lglu32 

./obj/lesson29.o: lesson29.cpp
    $(CC) -c -o ./obj/lesson29.o lesson29.cpp $(CC_TARGET_01)  
$(CFLAGS_TARGET_01)
----------------------------------------------------
I hope this answers your question Emre.

Best wishes and good luck

Nick

make -v gives following (in the directory that Im trying to compile 
"/c/Dev-C++/stlport/src/")
-------------------------------------------------------------------
$ make -v
GNU Make version 3.77, by Richard Stallman and Roland McGrath.
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98
        Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

Report bugs to <bug...@gn...>.
--------------------------------------------------------------------
Ive asked the version of make that comes with MSYS (in "/bin/"); 
the result:
--------------------------------------------------------------------
$ ./make.exe -v
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i386-pc-msys
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
        Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

Report bugs to <bug...@gn...>.
-------------------------------------------------------------


-----Original Message-----
From: Jean le Roux [mailto:je...@in...] 
Sent: Wednesday, March 27, 2002 6:30 PM
To: Emre Turkay
Cc: min...@li...
Subject: Re: compiling stlport

On Wed, Mar 27, 2002 at 06:11:50PM +0200, Emre Turkay wrote:
> I have installed Dev-C++ and using mingw compiler coming with it.  
> gcc --version tells 2.95.2
> Dev-C++ is installed in C:\Dev-C++ directory; gcc and make is in;
> C:\Dev-C++\bin directory.

> Because /c/Dev-C++/Bin/ is coming before /bin; the make.exe must be
from
> mingw package. 

do a "make -v" and see what the "Built for {foo}" says, that will tell
us which one is being used.

> I also think that is a path problem; does anybody know if the stlport
> lib. requires includes/libs of the installed compiler ?  If this is
the
> case, I think it cannot find those files...

It should, it is building a lib to be used when linking with that
compiler. I read in the INSTALL file that one can customise the
STLport to implement iostreams as wrappers for existing iosteam
classes.. that would definitely imply the need for a set of cimplier
headers.

Where in all this do you fir MSys in ? It looks like you simply use
the mingw-gcc and such, with Dev-C++ (with which i'm not familiar
with). 

-- 
Jean le Roux
Binary Entropy Catalyst

Cellular:	083 505 6443

There are many intelligent species in the universe, and they all own
cats.

-----Original Message-----
From: Emre Turkay [mailto:emr...@bi...] 
Sent: Wednesday, March 27, 2002 6:12 PM
To: 'Jean le Roux'
Subject: compiling stlport

I have installed Dev-C++ and using mingw compiler coming with it.  
gcc --version tells 2.95.2
Dev-C++ is installed in C:\Dev-C++ directory; gcc and make is in;
C:\Dev-C++\bin directory.

My path variable is:
------------------------------------------------------------------------
--
$ echo $PATH
/c/Dev-C++/:/c/Dev-C++/Bin/:/c/Dev-C++/Include/:/bin:/mingw/bin:/c/Progr
am
Files/Inprise/vbroker/bin:/c/PROGRA~1/Borland/CBUILD~1/Projects/Bpl:/c/P
ROGRA~1/Borland/CBUILD~1/Bin:/c/WINNT/system32:/c/WINNT:/c/WINNT/System3
2/Wbem:/c/rware69/lib:/c/rware69/inso:/c/rware69/bin:/c/Program
Files/Microsoft SQL Server/80/Tools/BINN:/c/Program Files/Microsoft
Visual Studio/Common/Tools/WinNT:/c/Program Files/Microsoft Visual
Studio/Common/MSDev98/Bin:/c/Program Files/Microsoft Visual
Studio/Common/Tools:/c/Program Files/Microsoft Visual
Studio/VC98/bin:/c/DJGPP/bin:/c/DJGPP/bin:.
------------------------------------------------------------------------
---

My /etc/profile content is:
-----------------------------------------------------------
export PATH="/bin:/mingw/bin:$PATH"
unset DOSDRIVE
unset DOSDIR
unset TMPDIR
unset TMP

USER="`id -un`"

# Set up USER's home directory
if [ -z "$HOME" ]; then
  HOME="/home/$USER"
fi

if [ ! -d "$HOME" ]; then
  mkdir -p "$HOME"
fi

export HOME USER

for i in /etc/profile.d/*.sh ; do
  if [ -f $i ]; then
    . $i
  fi
done

export MAKE_MODE=unix
-----------------------------------------------------------

As shown above; I have manually added following dirs. to the PATH
variable.
/c/Dev-C++/:/c/Dev-C++/Bin/:/c/Dev-C++/Include/

Because /c/Dev-C++/Bin/ is coming before /bin; the make.exe must be from
mingw package. 

I also think that is a path problem; does anybody know if the stlport
lib. requires includes/libs of the installed compiler ?  If this is the
case, I think it cannot find those files...

Thanx for helps...

emre
emr...@bi...

-----Original Message-----
From: Jean le Roux [mailto:je...@in...] 
 
I presume you ahve both MinGW and MSys installed, otherwise this
whole discussion is a bit pointless :)

I cant seem to produce you results over here. Where is your Mingw
installed, and what does your etc/profile say? I suspact it's a path
problem, as in the wrong compiler might be invoked.

also, which versions of MinGW and MSys are you running ?

> c:\Dev-C++\Bin\make.exe: *** [../lib/obj/MINGW32/ReleaseD/fstream.o]

What package is this make.exe from ?

Is there any tip for compiling stlport with mingw? I have downloaded
stlport but couldnt to compile it.

Emre
emr...@bi...


-----Original Message-----
From: min...@li...
[mailto:min...@li...] On Behalf Of Oscar
Fuentes
Sent: Wednesday, March 27, 2002 3:24 PM
To: min...@li...
Subject: Re: [Mingw-users] problem with str.append(InputIterator,
InputIterator)

The problem is the old non-compliant library that comes with gcc
2.95.x. Unless you are supporting legacy code, use STLPort
(www.stlport.org). This will save you lots of problems. Your code is
correct and compiles ok with stlport.

-- 
Oscar


_______________________________________________
MinGW-users mailing list
Min...@li...

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