Re: [Mingw-users] Building DLLs using MinGW & libtool

[Earnie Boyd <earnie_boyd@ya...>]

Do you have the msysDTK?  And msysDVLPR?

All autoconfiguration tools must have the same prefix, that's why I
provided the msysDTK.  I have the configured all of the tools to
--prefix=/usr.

Earnie.

Bob Friesenhahn wrote:
> 
> While attempting to build a DLL under MinGW, MSYS, using the CVS
> version of libtool and gcc 2.95.3-6, I see these warnings printed by
> libtool:
> 
>

Re: [Mingw-users] Register as a system Process

[Grzegorz Owsiany <grow@fn...>]

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/win9x/95func_3t0z.asp

First you must find a handle to RegisterServiceProcess function in
kernel32.dll, after this call it with NULL,1 there is piece of my MASM32
code:

...
sz_kerneldll = "kernel32.dll"
sz_RegisterServiceProcess="RegisterServiceProcess"
...
  hidefunc                   dd ? ;
...
invoke  GetModuleHandle, ADDR sz_kerneldll
or      eax, eax                
jz      not_exists
invoke  GetProcAddress, eax, ADDR sz_RegisterServiceProcess
or      eax, eax
jz      not_exists
mov   [hidefunc], eax   
push    1      
push    0      
call   [hidefunc]   
not_exists:

Re: [Mingw-users] GCC Env. Config. & Dyna Libs - Questions.

[Tomasz Pona <cochisek@po...>]

----- Original Message -----
From: "Luke Dunstan" <coder_infidel@...>
To: "Koczis" <cochisek@...>
Cc: "mingw-users" <mingw-users@...>
Sent: Tuesday, June 11, 2002 4:36 AM
Subject: Re: [Mingw-users] GCC Env. Config. & Dyna Libs - Questions.


>
> ----- Original Message -----
> From: "Koczis" <cochisek@...>
> To: <mingw-users@...>
> Sent: Tuesday, June 11, 2002 7:35 AM
> Subject: [Mingw-users] GCC Env. Config. & Dyna Libs - Questions.

To make context of this msg clearer I actually decided to slightly change
its order.

> Based on your questions, I expect that you have only used dynamic
libraries
> on *nix until now. I don't know how they work on *nix, but on Windows they
> are DLLs which have "import libraries" that tell the compiler/OS which DLL
> the functions are in. Mingw contains many import libraries like
> "libkernel32.a", but they are named in the same way as static libraries.

Look at that sentence:

> > I have some trouble with GCC env. config. Though this driver-utility
> > philosophy is doing good job finding paths without my help

... it explains in somehow twisted way that I wasn't *nix developer - and
still I'm not. :)
So thats why:
    - I choosed MinGW not Cygwin (there are too many causes to explain them
here),
    - I'm not familiar with some POSIX utils philosophy of working.
It is now clear to me that searching multiple standard paths by g++ is
default and obvious.

Now I'll try to be brief.

> > The question is: How to in simpliest way narrow the range of search
paths
> > of utils or even fix standard library locations to them?
>
> Firstly, I am not sure why you want to do this and I doubt that you could
> make much difference to the build time, but if you do find ways to
> noticeably improve build time (particularly for C++), I am sure many users
> would be interested.

I don't know on how powerful machines you work but those are probably at
least Pentium Pros with over 64MB of RAM. You see - I have simple 166MHz
with 32MB RAM and NT, and have to keep a memory defragmenter running
constantly - without it the session dies after approximately 2-3 hours. So
every one opened handle less - saves my time, especially when that prevents
the system from accessing pagefile and memory defragmenter from freeing
resources.

> > I've experimented with env. variables and command-line options and
> > worked out a best settings I could.

It means that I reached satisfactory results - I've speeded up the link (but
only link) process by observable amount of time. So it isn't bad but the one
more thing I need to feel happy is to cut that redundand environment that
g++ produces in such a nonsense way:
-L/mingw/lib/gcc-lib/mingw32/3.1/../../../../mingw32/lib"
"-L/mingw/lib/gcc-lib/mingw32/3.1/../../../../mingw32/lib"
"-L/mingw/lib/gcc-lib/mingw32/3.1/../../.."
"-L/mingw/lib/gcc-lib/mingw32/3.1/../../.."

Of course on better hardware the ld speed-up won't be observable at all.

And whats that?
[...]
ignoring nonexistent directory "/mingw/mingw32/bin/include"       // ?!
ignoring nonexistent directory "/mingw/bin/include"                      //
?!
GNU CPP version 3.1 (cpplib) (80386, BSD syntax)
GNU C++ version 3.1 (mingw32)
        compiled by GNU C version 3.1.
ignoring nonexistent directory "/mingw/mingw32/include"            // ?!
ignoring nonexistent directory "/mingw/mingw32/include"            // ?!
ignoring nonexistent directory "/usr/local/mingw32/include"         // ?!
[...]

- forgive me: I'm optimalistic-thinking guy.

> > /mingw/lib/gcc-lib/mingw32/2.95.3-6
> > /mingw/lib/gcc-lib/mingw32/2.95.3-6/include
> > /mingw/lib/gcc-lib/mingw32/2.95.3-6/units
> > /mingw/lib/gcc-lib/mingw32/3.1
> > /mingw/lib/gcc-lib/mingw32/3.1/include
> > /mingw/lib/gcc-lib/mingw32/3.1/include/objc
>
> Please note that installing both versions of the compiler in the same
place
> may cause problems because I don't think GCC 3.1 is really designed to
> support this usage. If you were planning on using the -V option to switch
> between them, you should read about it on the GCC discussion and bug lists
> because I believe the option doesn't really work.

I didn't install 2.95.3-6 gcc - these libraries come with gpc package.

> I would suggest using forward slashes in any paths supplied to GCC, and it
> seems to convert them to forward slashes anyway.

I tried both ways - same effect (currently I have POSIX paths).

> >
> > GCC_EXEC_PREFIX=C:\mingw\lib\gcc_lib\
>
> That should be "gcc-lib", not "gcc_lib". I really doubt whether this will
> make a difference because gcc should find this directory without any
> searching.

Of course - this is the typo - sorry!

> > COMPILER_PATH=C:\mingw\bin\
>
> According to the manual, this path list is used to find subprograms (e.g.
> "cc1plus.exe"), which are not in mingw/bin, and is only used if the
programs
> cannot be found using GCC_EXEC_PREFIX (which should always succeed).
>

Yes - I read that and... experienced that g++ doesn't have any problems
invoking the cc*.exe with that variable set,  whereas it supplies nice
looking paths to as and ld instead of  '/../../../../'-ones when that
variable isn't set.

> > CPATH=C:\mingw\include\
> > CPLUS_INCLUDE_PATH=C:\mingw\include\g++-v3\
>
> Based on the output of "gcc -v", this only adds directories to the search
> path that are already there. I can't see how this will speed anything up.
>
> > LIBRARY_PATH=C:\mingw\lib\
>
> The only difference this seems to make is passing
> "c:/apps/mingw/gcc-3.1/lib/crt2.o" to the linker instead of
> "c:/apps/mingw/gcc-3.1/lib/gcc-lib/mingw32/3.1/../../../crt2.o". In theory
I
> suppose this could make a difference but I doubt it would be measurable
> since the file should only be loaded once.
>

At least it cleans something.

Summarizing env. variables: I set them because some documentation (probably
MSYS, but I'm not sure) mentions doing so.

> > So I'm using -static option to force linker not to search for dynamic
> > libraries. But when I'll need to link a dynamic-one how will I do it
> > preserving this state?
>
> Since all import libraries supplied with mingw are named like static
> libraries, and since there are no DLLs in the lib directories, this switch
> should work without problems. However this may change in future versions,
> and you would need to make sure that your import libraries are named
> properly.

Does it mean that I will need to update their names manually?

>
> > Another two questions are:
> > - if I decide to link standard libraries dynamically, will I have to
> > download sources and rebuild them or is it possible to make them without
> > sources? (this must sound silly to everyone who knows it but I just must
> > ask),
> > - which std. libraries are better to link dynamically and which to keep
> > static? - it's of course very wide subject but I need your opinion.
>
> Firstly, almost all standard libraries used with Mingw are already linked
> dynamically (e.g. the C library and the OS API DLLs).

I understand, that almost all .a files in MinGW are actually import
libraries forcing built application to load some DLL's at execution-time. Is
that correct? If so which are those DLL's?

> Luke Dunstan

Thank you very much for your support.
Koczis.

P.S. This and previous message are posted by me to get info needed in
optimization of not-so-far-ago-downloaded MinGW. I think one more will be
good enough and I should get to real work :)

[Mingw-users] RE: Building DLLs using MinGW & libtool

[Howard Chu <hyc@hi...>]

I reported the same libtool bug a couple months ago. No response. The
libtool script assumes any file with a ".a" suffix is a static library, it
doesn't recognize that it's in fact a valid import library for a DLL. I
hacked my libtool script up to skip the filetype check and just blindly link
what I tell it to link. (Obviously it would be better in the long run to fix
the filetype check, but I knew what I was linking, and just wanted it to
shut up and do it...)

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: libtool-admin@... [mailto:libtool-admin@...]On Behalf Of
> Bob Friesenhahn
> Sent: Tuesday, June 11, 2002 2:01 PM
> To: mingw-users@...
> Cc: libtool@...
> Subject: Building DLLs using MinGW & libtool
>
>
> While attempting to build a DLL under MinGW, MSYS, using the CVS
> version of libtool and gcc 2.95.3-6, I see these warnings printed by
> libtool:
>
> *** Warning: linker path does not have real file for library -lgdi32.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libgdi32 and none of the candidates passed a file format test
> *** using a file magic. Last file checked: /usr/local/lib/libz.a
>
> *** Warning: linker path does not have real file for library -lm.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libm and none of the candidates passed a file format test
> *** using a file magic. Last file checked: /usr/local/lib/libz.a
> *** The inter-library dependencies that have been dropped here will be
> *** automatically added whenever a program is linked with this library
> *** or is declared to -dlopen it.
>
> *** Since this library must not contain undefined symbols,
> *** because either the platform does not support them or
> *** it was explicitly requested with -no-undefined,
> *** libtool will only create a static version of it.
>
> However, I see the file GDI32.DLL in my PATH in the directory
> "/c/WINDOWS/SYSTEM32/".  I have tried to add a -L option to reference
> that directory, but it didn't help.
>
> I notice that MinGW libraries are named like "libgdi32.a".
> Regardless of the naming differences, it seems that it should be
> possible to build DLLs using libtool under MinGW.
>
> There are some other warnings printed as well for static libraries
> built with libtool:
>
> *** Warning: This system can not link to static lib archive
> /usr/local/lib/libwmflite.la.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have.
>
> I assume that these warnings are insignificant since the same list of
> libraries will be applied when building executables.  However, maybe I
> am wrong.  Maybe all libraries linked to the DLL need to be DLLs?
>
> What is the trick to getting this to work?
>
> Thanks,
>
> Bob
> ======================================
> Bob Friesenhahn
> bfriesen@...
> http://www.simplesystems.org/users/bfriesen
>
>
> _______________________________________________
> Libtool mailing list
> Libtool@...
> http://mail.gnu.org/mailman/listinfo/libtool

[Mingw-users] Building DLLs using MinGW & libtool

[Bob Friesenhahn <bfriesen@si...>]

While attempting to build a DLL under MinGW, MSYS, using the CVS
version of libtool and gcc 2.95.3-6, I see these warnings printed by
libtool:

*** Warning: linker path does not have real file for library -lgdi32.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libgdi32 and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/local/lib/libz.a

*** Warning: linker path does not have real file for library -lm.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libm and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/local/lib/libz.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

However, I see the file GDI32.DLL in my PATH in the directory
"/c/WINDOWS/SYSTEM32/".  I have tried to add a -L option to reference
that directory, but it didn't help.

I notice that MinGW libraries are named like "libgdi32.a".
Regardless of the naming differences, it seems that it should be
possible to build DLLs using libtool under MinGW.

There are some other warnings printed as well for static libraries
built with libtool:

*** Warning: This system can not link to static lib archive /usr/local/lib/libwmflite.la.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

I assume that these warnings are insignificant since the same list of
libraries will be applied when building executables.  However, maybe I
am wrong.  Maybe all libraries linked to the DLL need to be DLLs?

What is the trick to getting this to work?

Thanks,

Bob
======================================
Bob Friesenhahn
bfriesen@...
http://www.simplesystems.org/users/bfriesen

Re: [Mingw-users] Undefined References

[<danny_r_smith_2001@ya...>]

 --- Matriark TerVel <matriark@...> wrote: > Hello all,
> 
> When trying to link an app (which has linked before fine in the past) i now
> get these linker errors. MinGW is in /usr/cross-tools and my liner line is:
> 

What are you doing differently now than in the "past"? What has changed?

Danny

> Matriark TerVel
> 
> Systems Administrator / Programmer
> Anti-Graal HQ
> http://opengraal.com
> 
> _______________________________________________________________
> 
> Multimillion Dollar Computer Inventory
> Live Webcast Auctions Thru Aug. 2002 - http://www.cowanalexander.com/calendar
> 
> 
> 
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
> 
> 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
- Find yourself a bargain!

[Mingw-users] Undefined References

[Matriark TerVel <matriark@re...>]

Hello all,

When trying to link an app (which has linked before fine in the past) i now get these linker errors. MinGW is in /usr/cross-tools and my liner line is:

g++ -o gserver.exe cfg.o gserver.o levels.o otherstuff.o pascalstrings.o convertedclasses.o passwords.o  -L/usr/cross-tools/i386-mingw32msvc/lib -L/usr/lib/mingw32 -L. -L/usr/cross-tools/lib/gcc-lib/i386-mingw32msvc/2.95.2 -L/usr/cross-tools/i386-mingw32msvc/lib -lstdc++ -lws2_32 libsqlite.a libz.a -lm 

the majority of the errors are:

/root/gserver-win32/src/convertedclasses.cpp:369: undefined reference to `istream::tellg()'
/root/gserver-win32/src/convertedclasses.cpp:370: undefined reference to `istream::seekg(long, ios::seek_dir)'
/root/gserver-win32/src/convertedclasses.cpp:375: undefined reference to `operator new[](unsigned)'
/root/gserver-win32/src/convertedclasses.cpp:376: undefined reference to `istream::read(char*, int)'
/root/gserver-win32/src/convertedclasses.cpp:383: undefined reference to `fstreambase::close()'
/root/gserver-win32/src/convertedclasses.cpp:383: undefined reference to `vtable for ifstream'
/root/gserver-win32/src/convertedclasses.cpp:383: undefined reference to `vtable for ifstream'
/root/gserver-win32/src/convertedclasses.cpp:366: undefined reference to `vtable for ifstream'
convertedclasses.o: In function `TStream::LoadFromFile(JString)':
/usr/cross-tools/include/g++-3/iostream.h:230: undefined reference to `VTT for ifstream'
/usr/cross-tools/include/g++-3/iostream.h:230: undefined reference to `VTT for ifstream'
/usr/cross-tools/include/g++-3/iostream.h:230: undefined reference to `VTT for ifstream'
convertedclasses.o: In function `TStream::LoadFromFile(JString)':
/root/gserver-win32/src/convertedclasses.cpp:366: undefined reference to `ios::~ios()'
/root/gserver-win32/src/convertedclasses.cpp:366: undefined reference to `VTT for ifstream'
/root/gserver-win32/src/convertedclasses.cpp:366: undefined reference to `vtable for ifstream'
/root/gserver-win32/src/convertedclasses.cpp:366: undefined reference to `vtable for ifstream'
/root/gserver-win32/src/convertedclasses.cpp:366: undefined reference to `vtable for ifstream'
convertedclasses.o: In function `TStream::LoadFromFile(JString)':
/usr/cross-tools/include/g++-3/iostream.h:230: undefined reference to `VTT for ifstream'
/usr/cross-tools/include/g++-3/iostream.h:230: undefined reference to `VTT for ifstream'
/usr/cross-tools/include/g++-3/iostream.h:230: undefined reference to `VTT for ifstream'
convertedclasses.o: In function `TStream::LoadFromFile(JString)':
/root/gserver-win32/src/convertedclasses.cpp:366: undefined reference to `ios::~ios()'
convertedclasses.o: In function `TStream::SaveToFile(JString)':
/usr/cross-tools/include/g++-3/streambuf.h:479: undefined reference to `vtable for ios'
convertedclasses.o: In function `TStream::SaveToFile(JString)':
/usr/cross-tools/include/g++-3/fstream.h:76: undefined reference to `VTT for ofstream'
/usr/cross-tools/include/g++-3/fstream.h:76: undefined reference to `fstreambase::fstreambase(char const*, int, int)'
/usr/cross-tools/include/g++-3/fstream.h:76: undefined reference to `VTT for ofstream'
/usr/cross-tools/include/g++-3/fstream.h:76: undefined reference to `ostream::ostream()'
/usr/cross-tools/include/g++-3/fstream.h:76: undefined reference to `vtable for ofstream'
/usr/cross-tools/include/g++-3/fstream.h:76: undefined reference to `vtable for ofstream'
/usr/cross-tools/include/g++-3/fstream.h:76: undefined reference to `vtable for ofstream'
/usr/cross-tools/include/g++-3/fstream.h:76: undefined reference to `vtable for ofstream'
convertedclasses.o: In function `TStream::SaveToFile(JString)':
/root/gserver-win32/src/convertedclasses.cpp:393: undefined reference to `ostream::write(char const*, int)'
/root/gserver-win32/src/convertedclasses.cpp:394: undefined reference to `fstreambase::close()'
/root/gserver-win32/src/convertedclasses.cpp:394: undefined reference to `vtable for ofstream'
/root/gserver-win32/src/convertedclasses.cpp:333: undefined reference to `vtable for ofstream'
convertedclasses.o: In function `TStream::SaveToFile(JString)':
/usr/cross-tools/include/g++-3/iostream.h:230: undefined reference to `VTT for ofstream'
/usr/cross-tools/include/g++-3/iostream.h:230: undefined reference to `VTT for ofstream'
/usr/cross-tools/include/g++-3/iostream.h:230: undefined reference to `VTT for ofstream'
convertedclasses.o: In function `TStream::SaveToFile(JString)':
/root/gserver-win32/src/convertedclasses.cpp:333: undefined reference to `ios::~ios()'
/root/gserver-win32/src/convertedclasses.cpp:396: undefined reference to `VTT for ofstream'
/root/gserver-win32/src/convertedclasses.cpp:333: undefined reference to `vtable for ofstream'
/root/gserver-win32/src/convertedclasses.cpp:333: undefined reference to `vtable for ofstream'
convertedclasses.o: In function `TStream::SaveToFile(JString)':
/usr/cross-tools/include/g++-3/iostream.h:230: undefined reference to `VTT for ofstream'
/usr/cross-tools/include/g++-3/iostream.h:230: undefined reference to `VTT for ofstream'
/usr/cross-tools/include/g++-3/iostream.h:230: undefined reference to `VTT for ofstream'
convertedclasses.o: In function `TStream::SaveToFile(JString)':
/root/gserver-win32/src/convertedclasses.cpp:333: undefined reference to `ios::~ios()'
convertedclasses.o: In function `TSocket::Connect(JString const&, int, bool)':
/root/gserver-win32/src/convertedclasses.cpp:439: undefined reference to `operator delete(void*)'
convertedclasses.o: In function `TSocket::Read()':
/root/gserver-win32/src/convertedclasses.cpp:498: undefined reference to `__WSAFDIsSet'
convertedclasses.o: In function `TSocket::Send(JString const&)':
/root/gserver-win32/src/convertedclasses.cpp:533: undefined reference to `__WSAFDIsSet'
convertedclasses.o: In function `TSocket::Accept()':
/root/gserver-win32/src/convertedclasses.cpp:560: undefined reference to `operator new(unsigned)'
convertedclasses.o: In function `TSocket::Close()':
/root/gserver-win32/src/convertedclasses.cpp:580: undefined reference to `closesocket'
convertedclasses.o: In function `fstreambase::~fstreambase()':
/root/gserver-win32/src/convertedclasses.cpp(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
passwords.o: In function `des_set_key':
/root/gserver-win32/src/fcrypt.h:349: undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
make: *** [gserver] Error 1
[root@... src]# 

Is there another library i should link or a header i should remove? any help is greatly appreciated. (btw, fcrypt.h is a version of fcrypt() by eric young)

-- 
Matriark TerVel

Systems Administrator / Programmer
Anti-Graal HQ
http://opengraal.com

[Mingw-users] Register as a system Process

[Amoediun Trepcoze <amoediun@am...>]

How Do u Register  your App as a System Process??
so your app not longer shows up in windows 98 tasklist  when u press 
ctrl+alt+del


can someone post some example code plz

L8r
Amoediun

[Mingw-users] Re: Crash in some Win32 environments

[Joerg Bruehe <joerg@sq...>]

Hi MinGW users,

this follow-up to my own posting is just to inform you of=20
the current state of affairs (as asked by Jose):

Joerg Bruehe wrote:
>=20
> Hi Jose (+ all others)!
>=20
> Jos=E9 Fonseca wrote:
> >
> > [...]
> >
> > Even if you gonna compile your program with MSVC it would be nice to
> > determine the cause of this problem (as this may not be an option to
>=20
> I fully agree.
>=20
> I try with MSVC for two reasons:
> - If the result works, I can give it to my colleague who needs it
>   as a tool, just so that he can proceed.
> - If the result (still) fails (what I hope), I get a proof that it
>   is _not_ a MinGW/"gcc" induced problem.

The MSVC generated version (using the original source code) also=20
crashed, but at a different place - so the error was shifted but=20
not removed.

The MSVC generated version also produces some messages (from internal=20
consistency checks) which the "gcc" generated version does not show,=20
until now I have no real explanation for that. My guesses are=20
a) it might be a lack of "zero-initialization" or=20
b) different placement of structure members (the program makes=20
   heavy use of "union"),=20
but priorities are such that I do not pursue that in depth.

>=20
> [...]
>=20
> The only clue I have is that the input file (which makes it crash
> on some platforms / in some environments) is quite large, so my
> program has built large internal tables. The space for these tables
> is allocated incrementally using "calloc", whose return code is
> always checked for errors - there were none.

To elaborate on this:=20
The program contains an array of 2048 elements.=20
When the input file needs more elements, a "calloc()" is done,=20
and the resulting address is converted into an array index=20
which is then used, in effect the array has large gaps in its=20
index range. I know this relies on a linear address space and so=20
is no proper C, but changing this original design seemed too high=20
an effort.

> The program crashes when it tries to follow some entries in the
> last chunk of table allocated.

As this "expansion with gaps" seemed dubious, I have increased=20
the initial array size from 2048 to 40,000. It might still be=20
expanded (that code was not removed), but that seems quite=20
unlikely.

>=20
> [...]
>=20
> If I knew the problem myself, I would be happy - I just have a symptom:
> - It crashes on two Win2000 "Professional" machines, one with
>   CygWin and one without.

With this increased array, the program works on those input files=20
which caused it to fail previously.=20
It works both as a MSVC- as well as a MinGW-"gcc"-generated binary.

> - It works on a Win2000 "Server" machine with CygWin
>   as well as on a WinNT 4.0 machine without CygWin.
> AIUI, the MinGW generated binary will use the local "MSVCRT" DLL,
> so that might make a difference between those platforms.

To me, it still seems that Win2000 "Professional" behaves different=20
from both Win2000 "Server" and WinNT as far as dynamic memory=20
allocation is concerned, but I have no further details.


Regards,
Joerg Bruehe

--=20
Joerg Bruehe, SQL Datenbanksysteme GmbH, Berlin, Germany
     (speaking only for himself)
mailto: joerg@...

Re: [Mingw-users] getopts.h

[<danny_r_smith_2001@ya...>]

 --- Travis Howell <kirben@...> wrote: > Earnie Boyd wrote:
> > Travis Howell wrote:
> >>
> >> I was just wondering why getopts.h is no longer part of the mingw
> >> packages ? and will it return ?
> >>
> >
> > You mean getopt.h, it comes from the libiberty package of GCC and is
> > GPL, so if you use it in your code, it will also be GPL.  Are you
> > saying it's not included in GCC-3.1?  That would be a good thing IMO.
> 
> Yes I meant getopt.h, which is part of the binutils package (at least
> binutils-2.11.90-20010915.tar.gz) along with mingw 1.1 but is missing from
> later versions of the binutils package.
> This project using getopt.h is GPL and I was hoping to avoid a rewrite of
> code.
> 
> 
The reason it was left out was because I forgot to update my makefile with a
patch to do that.  Also binutils and GCC now have a new configure switch to
install libiberty  headers with the lib.  I can activate that switch in next 
binutils release and install those headers in subdir include/liberty.

However, getopt.h is _not_ one of the headers installed by default. This is
what libiberty installs:

ansidecl.h
demangle.h
dyn-string.h
fibheap.h
floatformat.h
hashtab.h
libiberty.h
objalloc.h
partition.h
safe-ctype.h
sort.h
splay-tree.h
ternary.h 


Danny

> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -
> http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
> 
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
> 
> 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
- Find yourself a bargain!

Re: [Mingw-users] getopts.h

[Travis Howell <kirben@op...>]

Earnie Boyd wrote:
> Travis Howell wrote:
>>
>> I was just wondering why getopts.h is no longer part of the mingw
>> packages ? and will it return ?
>>
>
> You mean getopt.h, it comes from the libiberty package of GCC and is
> GPL, so if you use it in your code, it will also be GPL.  Are you
> saying it's not included in GCC-3.1?  That would be a good thing IMO.

Yes I meant getopt.h, which is part of the binutils package (at least
binutils-2.11.90-20010915.tar.gz) along with mingw 1.1 but is missing from
later versions of the binutils package.
This project using getopt.h is GPL and I was hoping to avoid a rewrite of
code.

Re: [Mingw-users] getopts.h

[Earnie Boyd <earnie_boyd@ya...>]

Travis Howell wrote:
> 
> I was just wondering why getopts.h is no longer part of the mingw packages ?
> and will it return ?
> 

You mean getopt.h, it comes from the libiberty package of GCC and is
GPL, so if you use it in your code, it will also be GPL.  Are you saying
it's not included in GCC-3.1?  That would be a good thing IMO.

Earnie.

[Mingw-users] about Internal compiler error

[lian <tru1@si...>]

hi, everybody
follow is a piece of sample code.
///////////////////////////////////////////////
class B;

class A{
public:
    void __stdcall foo(B b);
};

class B {
};
///////////////////////////////////////////
when compile with gcc(version 2.95.3-6 (mingw special)),
I get an Internal compiler error.
But I'am not sure. Is it really an internal bug?

RE: [Mingw-users] c++ question: Explicit class template instantiation [OT?]

[Esa Vuokko <esa.vuokko@bo...>]

    Luke Dunstan wrote:

    I don't know how other compilers do it, but the
    "-fno-implicit-inline-templates" option may do what you want.
    According to
    the GCC manual I think the reason this isn't the default is to allow the
    module that uses the template to be compiled without
    optimisation, meaning
    that it would not inline anything.

I think that those inline should be there in any case,
because explicit instantiation for classes is supposed to
instantiate all possible members for classes.  And inline
functions need to be present in case someone wants the
address of one, and copies of them should be removed in
final executable because of ODR.

Anyway, standard requires (my reading) that those inline
functions are instantiated (no savings in compiletime) and
there is only one copy of function (not counting inlined
bodies) in executable (because of ODR).  That leaves
savings to object and library filesizes.  Playing around
exported inline functions sounds a bit dangerous to me,
but I haven't tried.


HTH,
Esa

----------------------------------------------------------
Esa Ilari Vuokko                          +358-50-544 8847
esa.vuokko@...
Bonum IT Oy                                http://www.bonumit.com
----------------------------------------------------------

Re: [Mingw-users] GCC Env. Config. & Dyna Libs - Questions.

[<danny_r_smith_2001@ya...>]

 --- Luke Dunstan <coder_infidel@...> wrote: > 
> ----- Original Message -----
> From: "Koczis" <cochisek@...>
> To: <mingw-users@...>
> Sent: Tuesday, June 11, 2002 7:35 AM
> Subject: [Mingw-users] GCC Env. Config. & Dyna Libs - Questions.
> 
> 
> 
> Firstly, I am not sure why you want to do this and I doubt that you could
> make much difference to the build time, but if you do find ways to
> noticeably improve build time (particularly for C++), I am sure many users
> would be interested.

This is being worked on in GCC trunks.
Precompiled headers are in pipeline for 3.2.  

<snip>
> 
> I just tried this and I must admit that I didn't know that the linker
> automatically looks for "lib*.dll.a", "*.dll.a", "lib*.dll" and "*.dll" in
> addition to "lib*.a". The first two are used as a convenient way of naming
> import libraries so that they do not conflict with static libraries of the
> same name. The other two are used to allow you to link directly with a DLL
> so that an import library is not required.
> 
> > So I'm using -static option to force linker not to search for dynamic
> libraries. But when I'll need to link a dynamic-one how will I do it
> preserving this state?


By default, if you specify -lfoo and the linker  sees both libfoo.dll.a and
libfoo.a in its seach path, it will use the "dll" import lib, libfoo.dll.a. 
The -static switch overrides this so that in my example above it would just use
libfoo.a and not interpret -lfoo as libfoo.dll.a. 

Danny

http://www.sold.com.au - SOLD.com.au
- Find yourself a bargain!

Re: [Mingw-users] GMINGW GCC 3.1 another defect?

[<danny_r_smith_2001@ya...>]

 --- Ioannis Vranos <noicys@...> wrote: > I do some rounding
experiments today, but GCC 3.1 produces strange
> results for the following code:

  ===snip===

> long double mround(long double number, const unsigned long depth)

===snip===

>   printf("%Lf\n", mround(0.1, 3));
>  
  


The problem is with MSCVRT version of printf.  It can't handle long double. 
The Cephes library has  alternate functions for long double IO, targeted for
DJGPP.  I will see if I can use this to provide long double IO for mingw.  One
day.

Danny



http://www.sold.com.au - SOLD.com.au
- Find yourself a bargain!

[Mingw-users] GMINGW GCC 3.1 another defect?

[Ioannis Vranos <noicys@ho...>]

I do some rounding experiments today, but GCC 3.1 produces strange
results for the following code:
 
#include <stdio.h>
#include <stdlib.h>
 
#include <math.h>
#include <float.h>
 
/* depth is: 0.12345 . That is if we want to round the number 1.23 to
the
   integral part we give mround(1.23, 0)
*/
 
long double mround(long double number, const unsigned long depth)
{
  if(depth>=DBL_DIG)
     return number;
     
  if(number>=0)
    return floor(number * pow(10, depth) + 0.5) / pow(10, depth);
    
  else
    return floor(number * pow(10, depth) - 0.5) / pow(10, depth);
}
 

int main(void)
{
 
  system("cls");
 
  printf("%Lf\n", mround(0.1, 3));
 

  return 0;
}
 
 
Compiled: 
> Executing: C:\Program Files\ConTEXT\ConExec.exe "gcc" "mround.c" -o
mround -ansi -pedantic-errors -Wall -fexpensive-optimizations -O3
-ffloat-store -mcpu=pentiumpro

 
produces:
 
-92559631349317808000000000000000000000000000000000000000000000.000000
 
 
However:
 
> Executing: C:\Program Files\ConTEXT\ConExec.exe "bcc32" -O2 -6 -q -A
"mround.c"

0.100000
 
 
> Executing: C:\Program Files\ConTEXT\ConExec.exe "icl" /EHa /G6 /nologo
/O3 /Qansi /Qc99 /Za /Qipo "mround.c"

0.100000
 
 
 
Casting doesn't help.
 
 
Things work reasonably when double is used.
 
 
Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.cjb.net
<http://www.noicys.cjb.net/>; 
* Alternative URL: http://run.to/noicys
 

Re: [Mingw-users] where is regex

[Christopher Faylor <cgf@re...>]

On Mon, Jun 10, 2002 at 05:27:39PM -0700, Paul G. wrote:
>Hi folks,
>
>  Please forgive the blow-by-blow commentary.

Hmm.  The original message said this:

>Sorry for the trivial question.  But here it goes:
>
>Where can I find regex.h in mingw32 and which lib should I link to ?

There is no mention of cygwin here.  Wu Yongwei is right.

Usually, if you are trying to be helpful, you do so by trying to avoid
confusing people.  Mentioning other package, like cygwin, or MS Platform
SDK, or whatever, which *wouldn't*even*solve*the*problem is just not
helpful.

There is no rationalization that you can propose that would make the
mention of cygwin helpful unless you wanted to actually point the user
at the cygwin project and propose that it was a solution.  It's possible
that would actually be a solution for the user. However, it looks like
there are probably mingw versions of the regex library available, so
there is really no reason to even mention cygwin at all in this case.

Instead, your responses have had a lot of words in them.  You mention
the word 'regex' repeatedly but the closest you've gotten to actually
answering the question was to suggest that a mingw version of Python had
a regex.h associated with it.

Supposing that there are corner cases where the incorporation of
cygwin's regex.h into a mingw program would be ok, is just, again, not
going to be helpful.  Assuming that the person has cygwin and was
somehow trying to mix -mno-cygwin and -I/usr/include is an illogical
leap based on facts not in evidence.  If you are a "newbie", you are
almost guaranteed to get into trouble if you try this.  So why even
mention it as an option?

cgf

Re: [Mingw-users] where is the document of "__attribute__((com_interface))"

[Luke Dunstan <coder_infidel@ho...>]

Apparently this attribute was not documented yet in GCC version 2.95.3, so a
quick Google search reveals:

http://www.la.utexas.edu/lab/software/devtool/gnu/gcc/gcc_121.html

Apparently this page refers to GCC version 2.97 (?), which was probably not
an official release, but it should be okay. If this documentation is not
enough then read some of the other pages that Google finds.

Luke

----- Original Message -----
From: "lian" <tru1@...>
To: "mingw" <mingw-users@...>
Sent: Tuesday, June 11, 2002 11:40 AM
Subject: [Mingw-users] where is the document of
"__attribute__((com_interface))"


> hi, Dunstan
> Thanks very much, for your good idea.
> well, where can I get the document of "__attribute__((com_interface))"?
> I had searched it in Info-html/gcc.html, but got nothing.
>
> Regards,
> lian
>
> --- Original Message from Luke Dunstan ---
>
> Message: 8
> From: "Luke Dunstan" <coder_infidel@...>
> To: "lian" <tru1@...>,
> <mingw-users@...>
> Subject: Re: [Mingw-users] about vtable implement (2)
> Date: Mon, 10 Jun 2002 17:28:11 +0800
>
>
> I haven't done any COM programming so I am basically guessing, but if you
> look in Mingw basetyps.h you will see some macros like DECLARE_INTERFACE()
> that are used to declare standard interfaces like IUnknown. The important
> part is that it uses "__attribute__((com_interface))", so you should try
> that and see what happens. You could also try GCC 3.1, because according
to
> the header file you don't need the special attribute for newer versions of
> GCC, and you also don't need -fvtable-thunks.
>
> Luke Dunstan
>
> --__--__--
>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
>
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>

[Mingw-users] where is the document of "__attribute__((com_interface))"

[lian <tru1@si...>]

hi, Dunstan
Thanks very much, for your good idea.
well, where can I get the document of "__attribute__((com_interface))"?
I had searched it in Info-html/gcc.html, but got nothing.

Regards,
lian

--- Original Message from Luke Dunstan ---

Message: 8
From: "Luke Dunstan" <coder_infidel@...>
To: "lian" <tru1@...>,
	<mingw-users@...>
Subject: Re: [Mingw-users] about vtable implement (2)
Date: Mon, 10 Jun 2002 17:28:11 +0800


I haven't done any COM programming so I am basically guessing, but if you
look in Mingw basetyps.h you will see some macros like DECLARE_INTERFACE()
that are used to declare standard interfaces like IUnknown. The important
part is that it uses "__attribute__((com_interface))", so you should try
that and see what happens. You could also try GCC 3.1, because according to
the header file you don't need the special attribute for newer versions of
GCC, and you also don't need -fvtable-thunks.

Luke Dunstan

--__--__--

Re: [Mingw-users] c++ question: Explicit class template instantiation [OT?]

[Luke Dunstan <coder_infidel@ho...>]

I don't know how other compilers do it, but the
"-fno-implicit-inline-templates" option may do what you want. According to
the GCC manual I think the reason this isn't the default is to allow the
module that uses the template to be compiled without optimisation, meaning
that it would not inline anything.

See:

http://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/C---Dialect-Options.html#C++%20Dia
lect%20Options

and:

http://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/Template-Instantiation.html#Templa
te%20Instantiation

Luke Dunstan

----- Original Message -----
From: "Wirawan Purwanto" <wirawan@...>
To: "MinGW Users" <mingw-users@...>
Sent: Tuesday, June 11, 2002 10:29 AM
Subject: [Mingw-users] c++ question: Explicit class template instantiation
[OT?]


> I have a problem when explicitly instantiating a class template using g++
3.
> I wonder if the following thing is a standard behavior of a C++ compiler,
or
> peculiar to G++ only:
>
> Suppose I have a class template named Matrix<class _the_number> in a file
> called "Matrix.h". Now I write a simple file Matrix_double.cpp which
> contains only:
>
> #include "Matrix.h"
> template class Matrix<double>;
>
> Now, when I inspect the resulting assembly code, all the inline
subroutines
> are emitted in it. How to get rid of these inline subroutines in g++
> (version 3), since I don't need them (they'll be inlined when actually
used
> anyway)? They just make the executable size fatter.
>
> Wirawan
>

Re: [Mingw-users] c++ question: Explicit class template instantiation [OT?]

[Wirawan Purwanto <wirawan@ca...>]

Well, I used -O3 switch, actually. I think *all* functions were inlined
there. If you're curious, try to compile the following file with g++ -O3
or -O2:

--- begin file ---

#include <stdio.h>

template <class _number>
    class Matrix
{
public:
    inline void proc1()
    {
        printf("Yes, ngamuk!\n");
    }
    inline void proc2()
    {
        printf("Yes, ngamuk 2!\n");
    }
    void proc3();
};

template <class _number>
inline void Matrix<_number>::proc3()
{
    printf("Yes, ngamuk 3!\n");
}

template class Matrix<double>;

class instant_: Matrix<double>
{
public:
    void proc4();
};

void instant_::proc4() { printf("yes"); }

--- end file ---

All functions above are so *simple*.

Wirawan

----- Original Message -----
From: "Wu Yongwei" <adah@...>
To: "MinGW-Users" <mingw-users@...>; "Wirawan Purwanto"
<wirawan@...>
Sent: Monday, June 10, 2002 10:43 PM
Subject: [Mingw-users] c++ question: Explicit class template instantiation
[OT?]


> Did you use the -O2 switch? No inline is actually done in non-optimizing
> mode. G++ may also choose not to inline the code because it is too
complex.
>
> Best regards,
>
> Wu Yongwei

[Mingw-users] c++ question: Explicit class template instantiation [OT?]

[Wu Yongwei <adah@ne...>]

Did you use the -O2 switch? No inline is actually done in non-optimizing
mode. G++ may also choose not to inline the code because it is too complex.

Best regards,

Wu Yongwei

--- Original Message from Wirawan Purwanto ---

Now, when I inspect the resulting assembly code, all the inline subroutines
are emitted in it. How to get rid of these inline subroutines in g++
(version 3), since I don't need them (they'll be inlined when actually used
anyway)? They just make the executable size fatter.

Wirawan

Re: [Mingw-users] GCC Env. Config. & Dyna Libs - Questions.

[Luke Dunstan <coder_infidel@ho...>]

----- Original Message -----
From: "Koczis" <cochisek@...>
To: <mingw-users@...>
Sent: Tuesday, June 11, 2002 7:35 AM
Subject: [Mingw-users] GCC Env. Config. & Dyna Libs - Questions.


>
> Hi! As I'm really newbie here - my 1st msg. will be adequately long... :)
>
>
> GCC Environment Configuration & Dynamic Libraries.
>
>
> 1. GCC Environment Configuration.
>
> I have some trouble with GCC env. config. Though this driver-utility
philosophy is doing good job finding paths without my help - I'm trying to
speed up building process by minimizing resources it uses (I don't have much
of them). I've experimented with env. variables and command-line options and
worked out a best settings I could. Still, when I switch the utils (in my
case: g++) verbose-output on, I see that g++ finds but ignores the real
existing directories and ld always fails to link libgcc.a at first time
because tries at wrong path.
>
> The question is: How to in simpliest way narrow the range of search paths
of utils or even fix standard library locations to them?

Firstly, I am not sure why you want to do this and I doubt that you could
make much difference to the build time, but if you do find ways to
noticeably improve build time (particularly for C++), I am sure many users
would be interested.

>
> I dowloaded latest ver. of GCC (and the rest of MinGW release) from this
site and installed as is (with minor corrections in placement of win32-api
libs because of existing /mingw/ base dir in .zip and moving make.exe to
/mingw/bin/, which was later renamed to mingw32-make.exe by MSYS install
process), so here's my dir-tree:
>
> /mingw
> /mingw/bin
> /mingw/doc
> /mingw/doc/gpc
> /mingw/doc/gpc/demos
> /mingw/doc/gpc/docdemos
> /mingw/include
> /mingw/include/g++-v3
> /mingw/include/g++-v3/backward
> /mingw/include/g++-v3/bits
> /mingw/include/g++-v3/ext
> /mingw/include/g++-v3/mingw32
> /mingw/include/g++-v3/mingw32/bits
> /mingw/include/GL
> /mingw/include/libiberty
> /mingw/include/readline
> /mingw/include/sys
> /mingw/info
> /mingw/info-html
> /mingw/info-html/gpc
> /mingw/lib
> /mingw/lib/gcc-lib
> /mingw/lib/gcc-lib/mingw32
> /mingw/lib/gcc-lib/mingw32/2.95.3-6
> /mingw/lib/gcc-lib/mingw32/2.95.3-6/include
> /mingw/lib/gcc-lib/mingw32/2.95.3-6/units
> /mingw/lib/gcc-lib/mingw32/3.1
> /mingw/lib/gcc-lib/mingw32/3.1/include
> /mingw/lib/gcc-lib/mingw32/3.1/include/objc

Please note that installing both versions of the compiler in the same place
may cause problems because I don't think GCC 3.1 is really designed to
support this usage. If you were planning on using the -V option to switch
between them, you should read about it on the GCC discussion and bug lists
because I believe the option doesn't really work.

> /mingw/libstdc++-html-USERS-3.1
> /mingw/man
> /mingw/man/man1
> /mingw/mingw32
> /mingw/mingw32/bin
> /mingw/mingw32/lib
> /mingw/mingw32/lib/ldscripts
>
> Currently I'm not using command-line switches (like -I, -L, -B), just set
correct env. variables (but don't know if to correct values):

I would suggest using forward slashes in any paths supplied to GCC, and it
seems to convert them to forward slashes anyway.

>
> GCC_EXEC_PREFIX=C:\mingw\lib\gcc_lib\

That should be "gcc-lib", not "gcc_lib". I really doubt whether this will
make a difference because gcc should find this directory without any
searching.

> COMPILER_PATH=C:\mingw\bin\

According to the manual, this path list is used to find subprograms (e.g.
"cc1plus.exe"), which are not in mingw/bin, and is only used if the programs
cannot be found using GCC_EXEC_PREFIX (which should always succeed).

> CPATH=C:\mingw\include\
> CPLUS_INCLUDE_PATH=C:\mingw\include\g++-v3\

Based on the output of "gcc -v", this only adds directories to the search
path that are already there. I can't see how this will speed anything up.

> LIBRARY_PATH=C:\mingw\lib\

The only difference this seems to make is passing
"c:/apps/mingw/gcc-3.1/lib/crt2.o" to the linker instead of
"c:/apps/mingw/gcc-3.1/lib/gcc-lib/mingw32/3.1/../../../crt2.o". In theory I
suppose this could make a difference but I doubt it would be measurable
since the file should only be loaded once.

>
> Could anyone give me his/her opinion, share experience or examples of
settings?
>
>
> 2. Dynamic Libraries.
>
> I didn't found any dynamically-linked libraries in binaries of current
MinGW release (maybe I searched bad).

Based on your questions, I expect that you have only used dynamic libraries
on *nix until now. I don't know how they work on *nix, but on Windows they
are DLLs which have "import libraries" that tell the compiler/OS which DLL
the functions are in. Mingw contains many import libraries like
"libkernel32.a", but they are named in the same way as static libraries.

> When I for the first time passed --verbose option to the linker, I saw it
trying to link dynamically enormous number of times every needed standard
library (with no effect of course) before it actually succeeded in doing so
statically.

I just tried this and I must admit that I didn't know that the linker
automatically looks for "lib*.dll.a", "*.dll.a", "lib*.dll" and "*.dll" in
addition to "lib*.a". The first two are used as a convenient way of naming
import libraries so that they do not conflict with static libraries of the
same name. The other two are used to allow you to link directly with a DLL
so that an import library is not required.

> So I'm using -static option to force linker not to search for dynamic
libraries. But when I'll need to link a dynamic-one how will I do it
preserving this state?

Since all import libraries supplied with mingw are named like static
libraries, and since there are no DLLs in the lib directories, this switch
should work without problems. However this may change in future versions,
and you would need to make sure that your import libraries are named
properly.

> Another two questions are:
> - if I decide to link standard libraries dynamically, will I have to
download sources and rebuild them or is it possible to make them without
sources? (this must sound silly to everyone who knows it but I just must
ask),
> - which std. libraries are better to link dynamically and which to keep
static? - it's of course very wide subject but I need your opinion.

Firstly, almost all standard libraries used with Mingw are already linked
dynamically (e.g. the C library and the OS API DLLs). The main exceptions
are libgcc and libstdc++, which are likely very difficult to build as
dynamic libraries (for gcc 3.1) due to the restrictions of Windows DLLs
(such as the fact that they cannot contain undefined symbols). It is my
understanding that some Mingw developers have been trying to fix this,
because applications currently cannot catch exceptions thrown by DLLs unless
libgcc (and libstdc++?) are built dynamically.

>
>
> Thank you.
> Koczis.
>

Luke Dunstan

[Mingw-users] c++ question: Explicit class template instantiation [OT?]

[Wirawan Purwanto <wirawan@ca...>]

I have a problem when explicitly instantiating a class template using g++ 3.
I wonder if the following thing is a standard behavior of a C++ compiler, or
peculiar to G++ only:

Suppose I have a class template named Matrix<class _the_number> in a file
called "Matrix.h". Now I write a simple file Matrix_double.cpp which
contains only:

#include "Matrix.h"
template class Matrix<double>;

Now, when I inspect the resulting assembly code, all the inline subroutines
are emitted in it. How to get rid of these inline subroutines in g++
(version 3), since I don't need them (they'll be inlined when actually used
anyway)? They just make the executable size fatter.

Wirawan