----- Original Message -----
From: "Koczis" <cochisek@...>
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:
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.
> 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.
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
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).
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.
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
> 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
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
> 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
> - 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.