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

On Wed, 31 Jan 2001 so...@wo... wrote:

> 1612 #if defined(__BORLANDC__) /* || defined(__MINGW32__) */
> 1613 	switch (info.u.s.wProcessorArchitecture) {
> 1614 #else
> 1615 	switch (info.wProcessorArchitecture) {
> 1617 #endif

That is something like MinGW does not handle unamed unions/structs by
default. Should be defined when including <windows.h>. The u.s version
should work anyway...

st...@lk...

[Copies to: Gurusamy Sarathy <<gs...@ac...>, Nick Ing-
Simmons <<ni...@ni...>]


Hello MinGW List,


I have some badness with trying to build Perl (5.6.0, current stable 
production release) under GCC to ask for your help with. Yes, building 
Perl *again* (I recently built 5.7 [devel branch] under MinGW on NT4). 
This time on a system running Win95 (and yes, I know that building Perl 
under that semi-OS is unsupported, but please read on).


I am using Cygwin for the bash support and the CygUtil "conresize.exe" 
and the "Win95Cmd.Exe" from the MS_SDK package. This allows me to 
run much in bash (with a scrollbar) and when not in bash (when actually 
running the dmakefile), COMSPEC is actually CMD.exe, not 
COMMAND.COM, the utterly broken and pitiful Win9x/DOS-ish 
command 'shell'. I am using the latest pieces of MinGW, all downloaded 
from Sourceforge last night. I am *not* using the MinGW that comes in 
the latest Cygwin distro (that is, I have all the 'real' latest MinGW set up 
as "/mingw" [C:\mingw mounted to "/mingw"]) and placed first in the 
$PATH env setting.


I get nearly finished building miniperl.exe (the first major landmark in 
the complete Perl build process) but it stumbles on the win32.c|h stuff, 
which was ported to MinGW by Nick Ing-Simmons. Here is the console 
output of my gcc errors as reported by `dmake':


---- console output -- watch for wrapping and low-flying owls ----

<FontFamily><param>Andale Mono</param>win32.c: In function `win32_uname':

win32.c:1614: structure has no member named `u'

win32.c:1619: warning: unreachable code at beginning of switch statement

win32.c: In function `Nt4CreateHardLinkW':

win32.c:2471: warning: initialization from incompatible pointer type

win32.c:2490: union has no member named `u'

win32.c:2491: union has no member named `u'

win32.c: In function `win32_link':

win32.c:2522: warning: assignment from incompatible pointer type

win32.c: In function `w32_DomainName':

win32.c:3638: warning: assignment from incompatible pointer type

win32.c:3640: warning: assignment from incompatible pointer type

win32.c:3658: warning: passing arg 2 of `WideCharToMultiByte' makes integer from pointer without a cast

win32.c:3662: warning: passing arg 2 of `WideCharToMultiByte' makes integer from pointer without a cast<FontFamily><param>Georgia</param>

----- end console output ------


I solved the first two trouble areas by commenting out this in the source:

LINE 1613: #if defined(__BORLANDC__) /* || defined(__MINGW32__) */


and here -

LINE 2489: #if defined(__BORLANDC__) /* || defined(__MINGW32__) */


That lets me get a little further. But why were those in there to begin 
with? The code in question in the first instance is:


----- code citation -- watch for wrapping ---


1612 #if defined(__BORLANDC__) /* || defined(__MINGW32__) */

1613 	switch (info.u.s.wProcessorArchitecture) {

1614 #else

1615 	switch (info.wProcessorArchitecture) {

1617 #endif


----- end code -----


Where does the "(info.u.s.wProcessorArchitecture)"  come from? It isn't in 
the current MinGW headers at all. Was it in an earlier release? If so why is 
it gone now?


The next one was:

----code citation -- watch for wrapping -----


2489 #if defined(__BORLANDC__) /* || defined(__MINGW32__) */

2490     StreamId.Size.u.HighPart = 0;

2491     StreamId.Size.u.LowPart = dwLen;

2492 #else

2493     StreamId.Size.HighPart = 0;

2494     StreamId.Size.LowPart = dwLen;

2495 #endif


---- end code -------


See? Strange stuff.


Now I am stumped presently (as of this writing) at this:

_sys_nerr                                         .\mini/win32.o

This is the output of a --cref flag placed on the run of gcc as linker. It was 
accompanied by "undefined reference" in the errout.


Hope somebody can shed some light. I can provide more diagnostic info 
(such as a HUGE lengthy list of #defines procured through the gcc -E -dD 
flags).


  Thanks!

    soren andersen



<nofill>
--
These days we're all supposed to believe that everyone's opinion is
equally valid, but sometimes you just have to stand up and say "Your
opinion is wrong, and here is why, in overwhelming detail."

   - ru...@ku...

A new version of w32api has been released. 
You can download it from SourceForge by following this link: 

<http://sourceforge.net/project/showfiles.php?group_id=2435&release_id=16770> 

You requested to be notified when new versions of this file 
were released. If you don't wish to be notified in the 
future, please login to SourceForge and click this link: 
<http://sourceforge.net/project/filemodule_monitor.php?filemodule_id=11550> 

A new version of w32api has been released. 
You can download it from SourceForge by following this link: 

<http://sourceforge.net/project/showfiles.php?group_id=2435&release_id=16769> 

You requested to be notified when new versions of this file 
were released. If you don't wish to be notified in the 
future, please login to SourceForge and click this link: 
<http://sourceforge.net/project/filemodule_monitor.php?filemodule_id=11550> 

A new version of mingw-runtime has been released. 
You can download it from SourceForge by following this link: 

<http://sourceforge.net/project/showfiles.php?group_id=2435&release_id=16693> 

You requested to be notified when new versions of this file 
were released. If you don't wish to be notified in the 
future, please login to SourceForge and click this link: 
<http://sourceforge.net/project/filemodule_monitor.php?filemodule_id=11598> 

A new version of mingw-runtime has been released. 
You can download it from SourceForge by following this link: 

<http://sourceforge.net/project/showfiles.php?group_id=2435&release_id=16692> 

You requested to be notified when new versions of this file 
were released. If you don't wish to be notified in the 
future, please login to SourceForge and click this link: 
<http://sourceforge.net/project/filemodule_monitor.php?filemodule_id=11598> 

Earnie Boyd wrote:
> I have despised RPM since I first laid eyes on it, didn't much like
> Debian's either.  Why complicate something so simple?  The best package
> manager is a correctly created Makefile which is created with GNU's
> autotools.

I agree entirely.  In fact it's been years since I downloaded a binary for any
free software package.  I have a rather large source tree that I use to build
for Linux (x86 and Alpha), Solaris and Mingw, all of which use different native
installers.  The beauty of GNU is making all these disparate targets work like
one (OK, that's a stretch for Mingw, but we do the best we can).  Inventing
yet-another packaging system doesn't help anything.

Mingw is always the black sheep because it's not self-hosting and never will
be... it's just too incapable.  But that may be a good thing anyway, since it
gives us an excuse to try the cross tools ;)

It seems to me that those who want a packaging system for Mingw are similar to
those who want an IDE, standard libs, etc. who are likely also related to those
who try to host their development on Mingw.  (That's fine for those who prefer
it, it's way too painful for me.)  That particular demographic might be happier
organizing and building a larger distribution that has Mingw at its core, though
it would likely not be Mingw, since it is my understanding that there are those
besides me who are not interested in expanding the role of Mingw.

All I personally want to see from Mingw is to keep it small, simple and
up-to-date. (I'd also like to see it become a better member of the GNU family. 
I'm afraid that if it weren't for Mumit's efforts, Mingw would never even be
heard of by most GNU developers.  Note that Cygwin is considered a secondary
evaluation platform for the upcoming 3.0 release, while Mingw is
characteristically nowhere to be found.)

Just my .02, of course.

--
Jeff Sturm
jef...@co...

Hi!  I'm in no hurry to update my cross build environment.  I was just
curious.   I've been keeping my binutils up to date using hte Sourceware
snapshots which seem to be working for me just fine.

Take your time......

Peace.....

Tom




Mumit Khan <kh...@Na...> on 01/31/2001 11:11:32 AM

To:   Tom...@di...
cc:   min...@li...
Subject:  Re: [Mingw-users] Maintaining Mingw cross build environment


On Wed, 31 Jan 2001 Tom...@di... wrote:

> Hi!  What's the best way to maintain my Linux-hosted, Mingw32 targetted
> cross-build environment?  I want to upgrade the Mingw runtime using the
> source-2000-03-27.zip source and I was just wondering if there was a more
> preferred way to keeping my cross-build environment up to snuff.....

I'm about to update my howto on this topic -- the current one is way too
old and crusty. If you can wait for a few days, I'll send you a copy to
critique.

Regards,
Mumit

"John van V." wrote:
> 
> I am involved in critical mission systems.
> 
> Tar.exe and a standardized file system are my package manager.
> 
> Use SSH for an example
> 
> 1) specify /opt/ssh for the install target
> 2) install it
> 
> then:
> 
> 3) find /opt/ -name bin -type d
> 4) use the output to create your binary path
> 
> Even better, install /opt/ssh.nnn where nnn is the verison number.
> Then link /opt/ssh to /opt/ssh.nnn, when you upgrade just change the link.
> 
> I make very good money doing very simple things.
> 
> Package managers, such as RPM only allow people to de-standardize file
> structures.
> 
> They should be eliminated.
> 

I have despised RPM since I first laid eyes on it, didn't much like
Debian's either.  Why complicate something so simple?  The best package
manager is a correctly created Makefile which is created with GNU's
autotools.

Earnie.

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

Reinhard, please stop posting to this list in HTML!
I would be glad to offer any Linux -> mingw32 cross
gcc advice I could, but I can't read your emails
since they are in HTML. Please send emails in
plain text only.

thanks
Mo DeJong
Red Hat Inc

On Wed, 31 Jan 2001 Tom...@di... wrote:

> Hi!  What's the best way to maintain my Linux-hosted, Mingw32 targetted
> cross-build environment?  I want to upgrade the Mingw runtime using the
> source-2000-03-27.zip source and I was just wondering if there was a more
> preferred way to keeping my cross-build environment up to snuff.....

I'm about to update my howto on this topic -- the current one is way too
old and crusty. If you can wait for a few days, I'll send you a copy to
critique.

Regards,
Mumit

Hi!  What's the best way to maintain my Linux-hosted, Mingw32 targetted
cross-build environment?  I want to upgrade the Mingw runtime using the
source-2000-03-27.zip source and I was just wondering if there was a more
preferred way to keeping my cross-build environment up to snuff.....

Peace......

Tom

Hi,

I finished highschool in 1999, and since then intensively studies =
programming.  I did have pascal (irrelevant), C and C++ skill already, =
however.  I decided to go for self-study, since it is both cheaper, and =
I can get much more done.  For example, at Technicon SA (I live in South =
Africa) you study for a programmer for 3 years, but only start with VB =
programming in the third year.  I taught myself VB in a few months by =
buying the 3rd-year book and studying it.  The price is, of course, I =
have no qualification, but luckily the programming industry are more =
after what you can do than what you studied.

I am learning Windows programming, using VB6 and Ming (if I'm rich  I will buy VC++, but for now Ming is adequate!)  I am also learning =
CGI and ASP, Access, etc.  Now my question is, what books would you =
suggest I get myself to study?  Remember, my goal is to become a =
programmer.  In particular, must I rather get "Programming the Windows =
API" or "Advanced Visual Basic 6" (those are examples) or what?  What =
books do you suggest I get, to best teach myself all I need to know?

Thank you,
Marius Myburg.

---------------------------------------------------------
Ing. Reinhard Jessich
Software Design
FREQUENTIS
A-1120 Wien, Spittelbreitengasse 34
http://www.frequentis.com
eMail: rje...@fr...
Phone: +43/1/81150/2395
Fax: +43/1/81150/2299
--------------------------------------------------------->>> earnie_boyd@ya=
hoo.com 01/31/01 04:37pm >>>
> > I had also a problem to create a program which uses a message box. It
> > worked on win98, but not on WinNT4.0. -> any ideas?

> You should use [gc]++ instead of gcc.  The g++ frontend will find the
> libstdc++.a library for you.
Thank you, it worked! I was so stupid, it is clear to use g++.

> Thanks, I may give this a try tonight.
I have a i686-pc-linux  system and I have tried it on a Mandrake 7.1 and a =
Debian 2.1 distribution and had no problems.
In the patches, you will find some ideas to improve Makefiles, sources and =
configure scripts. I hope you will  put them to the official release, if =
all has worked with your try.

Regards,
            Reinhard

> Reinhard JESSICH wrote:
> 
> >> Hello,
> >> I want to create a linux-hosted gcc, which generates Win32
> binaries.
> I have build it from the cygwin sources. This was a hard work to
> figure out all problems and fixing them.
> The current version I have, sems to work, but I have problems using
> c++.
> The linker doesn't find the libstdc++.a. I have put the library to the
> link command and it worked, but this is no solution for me. the
> command is to do this is:
> ../cross-tools/bin/i386-mingw32msvc-gcc -o test test.o
> ../cross-tools/lib/gcc-lib/i386-mingw32msvc/2.95.2-6/libstdc++.a
> Normaly the linker should know where to find the library. -> any ideas
> to tell this the linker?
> I had also a problem to create a program which uses a message box. It
> worked on win98, but not on WinNT4.0. -> any ideas?
> 

You should use [gc]++ instead of gcc.  The g++ frontend will find the
libstdc++.a library for you.

> Attached you will find the patches and the script to build the
> compiler.
> 

Thanks, I may give this a try tonight.

Earnie.

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

I am involved in critical mission systems.

Tar.exe and a standardized file system are my package manager.

Use SSH for an example

1) specify /opt/ssh for the install target
2) install it

then:

3) find /opt/ -name bin -type d
4) use the output to create your binary path 

Even better, install /opt/ssh.nnn where nnn is the verison number.
Then link /opt/ssh to /opt/ssh.nnn, when you upgrade just change the link.

I make very good money doing very simple things.

Package managers, such as RPM only allow people to de-standardize file
structures.

They should be eliminated.

Thank you for your cooperation ;)



--- "V.Krishna Kumar" <v_k...@we...> wrote:
> Hello All!,
> 
> Is anybody working on a package manager for mingw32 ?
> 
> How about using Ant/XML <http://jakarta.apache.org> for building a
> package manager ?
> 
> cheers,
> Krishna Kumar <v_k...@op...>
> 
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
> 
> You may change your MinGW Account Options at:
> http://lists.sourceforge.net/lists/listinfo/mingw-users


=====
John van Vlaanderen

      #############################################
      #    CXN, Inc. Contact:  jo...@th...   #               #
      #      Proud Sponsor of Perl/Unix of NY     #
      #        http://puny.vm.com                 #                 
      #############################################

__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

Hello All!,

Is anybody working on a package manager for mingw32 ?

How about using Ant/XML <http://jakarta.apache.org> for building a
package manager ?

cheers,
Krishna Kumar <v_k...@op...>

Franco Bez wrote:
> Am Die, 30 Jan 2001 schrieb Christian Edward Gruber:
> >Sorry, typo.  I meant the question to be shlib.  Same question but with
> >libobjc.so/libobjc.dll

Only want to add that it is very important to use only a *single*
libobjc (either always link against the import library or against the
static one).
This is also different to Unix .so - symbols end up in private
name/storage-spaces with DLLs, so if you don't watch out, you can end up
with multiple ObjC environments (class registries etc) in a single
process.

> PS: static libraries are NOT linked at all. Static libraries are ONLY an
> archive of object files. (Just like a zip file, but uncompressed)
> So, a static library does not USE any other library, but it might require that
> you link to other libraries as well, when You intend to link to that static
> library.

I thought so, which is why I wondered about Christian's question as well
:-)

Helge
-- 
SKYRIX Software AG  http://www.skyrix.com/
Join the team:      http://www.skyrix.com/de/jobs/index.html

Mumit,

Thanks for your feedback. Here is my proposed patch. As explained in the
comments it is not possible to check for the version string since MINGW32
can't be compile with GCC 2.8.1, so it is compile with GCC 2.9.x but used
under GCC 2.8.1. I think that the comments here make this explicit.

Comments ?

<<
*** crt1.c.orig Tue Jan 30 17:07:56 2001
--- crt1.c Wed Jan 31 10:25:12 2001
***************
*** 186,191 ****
--- 186,203 ----
     */
    _mingw32_init_fmode ();
  
+ #ifdef	__GNUC__
+   /* CTOR initialization, this is a workaround for GCC compiler version 2.8.1.
+    * Later version of GCC (like GCC 2.9.x) generate a call to __main, but GCC
+    * 2.8.1 does not and this is required to have proper code initialization. 
+    * The function __main is idempotent, so calling it here is safe. Since
+    * MINGW32 runtime needs to be compiled with GCC 2.9.x (even if used by GCC
+    * 2.8.1 compiler) it is not possible to check version using __VERSION__
+    * string.
+    */
+   __main ();
+ #endif
+   
    /*
     * Call the main function. If the user does not supply one
     * the one in the 'libmingw32.a' library will be linked in, and
>>

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Hello MinGW users! I was just trying to get the Sonique Visual plugin 
example to compile with MinGW, and it worked without any modification.

Sonique is a popular audio player which supports audio input/output 
plugins as well as visualization plugins. For more inmformation, visit

http://www.sonique.com

I downloaded the "Example plugin" in the developer's area. It is meant 
for Visual C (that's what it says), but I got it to compile under MinGW 
using "dllwrap", on the ".o" file.
Hoping to hear something from others.

A.Kumar

Hi,
You used "trial/*"
The FAQ is at http://www.mingw.org/mingwfaq.shtml.

Regards
Sudhir
----- Original Message -----
From: "Herv=E9 PARISSI" <hpa...@ma...>
To: <min...@li...>
Sent: Wednesday, January 31, 2001 1:28 PM
Subject: Re: [Mingw-users] http://www.mingw.org site has been updated


http://www.mingw.org/trial/htdocs/mingwfaq_new.shtml =3D> Error 404 !

Herve PARISSI
"You assume too much" (The Menace Phantom)

----- Original Message -----
From: <Ear...@Ya...>
To: <min...@li...>
Sent: Wednesday, January 31, 2001 3:32 AM
Subject: [Mingw-users] http://www.mingw.org site has been updated


> I finally took the plunge and updated the www.mingw.org site.  This
> includes a new FAQ and other documentation.
>
> Earnie.



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

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

http://www.mingw.org/trial/htdocs/mingwfaq_new.shtml =3D> Error 404 !

Herve PARISSI
"You assume too much" (The Menace Phantom)

----- Original Message -----=20
From: <Ear...@Ya...>
To: <min...@li...>
Sent: Wednesday, January 31, 2001 3:32 AM
Subject: [Mingw-users] http://www.mingw.org site has been updated


> I finally took the plunge and updated the www.mingw.org site.  This
> includes a new FAQ and other documentation.
>=20
> Earnie.

On Mon, 29 Jan 2001, fulco bohle wrote:

> Does anyone has problems using the _builtin_apply and _builtin_return
> functions and for example the DocumentProperties Win32 API function ?
> The two functions dislike each other which will result in float stack
> errors. When I replace _builtin_apply with my own function/macro
> combination which reads:

Good question. I don't know if __builtin_apply and friends work with
STDCALL/WINAPI functions, which use a different calling convention
than the usual CDECL ones. 

I'm not sure I understand what you're doing, so you may indeed be
running into a different problem I'm not aware of. Are you trying to
call DocumentProperties or other WIN32 API routines using the GCC
__builtin* facilities, or is it something else?

> Where can I find the internals of __builtin_apply or __builtin_return ?

In the GCC sources of course.

> PS. I am trying to make a smal example which will crash definitly.

That is be the first step in finding a reasonable solution, if any, to 
this problem.

Perhaps not a good time to make my usual statement -- if you use such
funky compiler specific extensions, it's bound to come back and bite
in the most embarassing places. I do know however that the __builtin_*
facilities are almost essential in writing certain type of code in
a clean manner, so my statement is geared towards "user level" code
that should be able to do without it.

Regards,
Mumit

On Tue, 30 Jan 2001, Appaiah Kumaraswamy wrote:

> Hello! I am a novice programmer, just programming for fun. I have been 
> using MinGW for a long time, and while browsing the headers, I found 
> this cool feature in stdlib.h. Two variables, _argv and _argc are 
> defined there, which allow non-console, ie. Windows apps to use the dos 
> "main ()" style argument handling. I think it's much better than using 
> the LPSTR variable in WinMain.

If you're using main(), a better way to handle this the portable way --
use the argv and argc arguments passed to main by the underlying OS.
  
  #include <stdio.h>
  #include <stdlib.h>
  int 
  main (int argc, char *argv[]) 
  {
    int i;
    for (i = 0; i < argc; i++)
      printf ("argv[%d] = %s\n", i, argv[i]);
    
    exit (0);
  }

instead of using non-portable schemes like _argv and _argc. Guaranteed
to work on all "non-freestanding" or "hosted" implementations. 
Freestanding implementations include embedded systems, like your toaster
or refrigerator of the future, that may not have such facilities.

> This thing also lets me get the module file name, by accessing _argv 
> [0]. But there's one gotcha, about which I would like to ask:
> 
> I have made an application in, say D:\CC++\, by name abc.exe, which 
> prints the value of _argv [ 0 ]. Now, if I GCC 2.95.2 (CRTDLL), to 
> compile the application, then the printout is:
> D:\CC__~1\abc.exe
> 
> but if I use GCC 2.95.2-1 (MSVCRT), the output is:
> D:\CC++\abc.exe
> 
> Does this show that the problem is in CRTDLL.DLL (outdation, maybe?), or 
> am I doing something wrong?

Yes, CRTDLL is obsolete and MS is not going to update it other than
possibly fixing major bugs. MSVCRT is the way to go.

Regards,
Mumit

Am Die, 30 Jan 2001 schrieb Christian Edward Gruber:
>Sorry, typo.  I meant the question to be shlib.  Same question but with
>libobjc.so/libobjc.dll
>

In Windows the DLLs are not as flexible as the shared object files in UN*X are.
You need a so called import library to link to a DLL. That's a static library
that defines the DLL's exports.

If Your DLL is linked to some other lib or DLL, 
and your application, that uses Your DLL, also uses functions from that other
lib 
You will definately have to link to both Your import-library AND the other lib.
That's because Your DLL does NOT provide the other lib's functionality, but
merely uses it.

Ciao,
  Franco

PS: static libraries are NOT linked at all. Static libraries are ONLY an
archive of object files. (Just like a zip file, but uncompressed)
So, a static library does not USE any other library, but it might require that
you link to other libraries as well, when You intend to link to that static
library.