Author Topic: Why 2 copies of "ar.exe", "as.exe", "dlltool.exe" etc?  (Read 6317 times)

jaegen

  • Guest
Why 2 copies of "ar.exe", "as.exe", "dlltool.exe" etc?
« on: November 02, 2006, 09:28:08 pm »
Perhaps a dumb question, but I've been curious about this for a while and haven't found the answer:

The wiki page describing how to compile wxWidgets for use with C:B (http://wiki.codeblocks.org/index.php?title=Compiling_wxWidgets_2.6.2_to_develop_Code::Blocks_%28MSW%29) says to add both "<MINGW>\bin" and "<MINGW>\mingw32\bin" to your PATH environment variable.  Why is this?  When I look at "<MINGW>\mingw32\bin", it seems to have EXEs which already exist in "<MINGW>\bin", and they seem to be identical. 

Here's what I have in "<MINGW>\mingw32\bin":

ar.exe
as.exe
dlltool.exe
ld.exe
nm.exe
objdump.exe
ranlib.exe
strip.exe

Can anyone explain this?  (I'm just curious - Code:Blocks is great and I'm having no problems)

Thanks

Jaegen

Online stahta01

  • Lives here!
  • ****
  • Posts: 7591
    • My Best Post
Re: Why 2 copies of "ar.exe", "as.exe", "dlltool.exe" etc?
« Reply #1 on: November 02, 2006, 11:02:35 pm »
Because, that's the way mingw.org does it; ask them the question.

Tim S
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Why 2 copies of "ar.exe", "as.exe", "dlltool.exe" etc?
« Reply #2 on: November 03, 2006, 10:04:15 pm »
There are not 2 copies, but 3... :)  Maybe more, but I know at least of 3.
Two of them have the "genuine" tool name as for example gcc, and one has the tool name prepended with mingw-.
I think the latter has to do with gcc's ability for cross-compilation, and no idea about the former. But yes, indeed... you'll have to ask the MinGW guys, since we really don't know.


While you're asking this, you might add the question why most paths are set like that:
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/bin/mingw32/3.4.5/
intead of more concise representations (plus, the forementioned search path doesn't even exist, what seems to be the case for about 50% of search paths...).

It is only a vague guess, but I think MinGW could be made noticeably faster without having to change any code, simply by using search path layouts that don't go up and down the filesystem and by only using search paths that actually exist. I have no figures how much overhead exactly we're talking about here, but if you include, say, 500 header files (think of #include <wx.h>), it might be quite something.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."