Necessary environment path settings?

[Roland Schwarz]

With the mingw 3.4.5 release it was possible to invoke
the compiler just by calling with an absolute path without
the need to set up the path variable before.

This is not true anymore for 4.2.1. I get a CreateProcess:
No such file or directory error message instead.
Has this been changed intentionally?

( I am talking about using mingw from the CMD.EXE without
MSYS. )

Any hints appreciated!

--
_________________________________________
  _  _  | Roland Schwarz
 |_)(_  | aka. speedsnail
 | \__) | mailto:roland.schwarz@...
________| http://www.blackspace.at

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[JonY-3]

Roland Schwarz wrote:

> With the mingw 3.4.5 release it was possible to invoke
> the compiler just by calling with an absolute path without
> the need to set up the path variable before.
>
> This is not true anymore for 4.2.1. I get a CreateProcess:
> No such file or directory error message instead.
> Has this been changed intentionally?
>
> ( I am talking about using mingw from the CMD.EXE without
> MSYS. )
>
> Any hints appreciated!
>

Hi,
strangely, mine works, and I don't have them in path either.

Try adding -v to the command line. There should be clues there.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[Roland Schwarz]

JonY wrote:
> Hi,
> strangely, mine works, and I don't have them in path either.
>
> Try adding -v to the command line. There should be clues there.

Already did so. Before I discovered the behaviour I had the cygwin
in my PATH. The as was picked up from there.

Can you try with an (almost) empty PATH?
Say just C:\mingw-4.2.1\bin;C:\Windows;C:\Windows\system32
in it?


--
_________________________________________
  _  _  | Roland Schwarz
 |_)(_  | aka. speedsnail
 | \__) | mailto:roland.schwarz@...
________| http://www.blackspace.at

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[Greg Chicares-2]

On 2008-03-23 12:45Z, Roland Schwarz wrote:
> With the mingw 3.4.5 release it was possible to invoke
> the compiler just by calling with an absolute path without
> the need to set up the path variable before.
>
> This is not true anymore for 4.2.1. I get a CreateProcess:
> No such file or directory error message instead.

It's best to paste the exact error message here.

What version of ms windows are you using? Is it "vista"?

> Has this been changed intentionally?
>
> ( I am talking about using mingw from the CMD.EXE without
> MSYS. )

Not reproduced here with ms windows "xp":

C:\tmp>PATH ''

C:\tmp>PATH
PATH=''

C:\tmp>\cygwin\MinGW-20070825-sjlj\bin\gcc -dumpversion
4.2.1-sjlj

C:\tmp>\cygwin\MinGW-20070825-sjlj\bin\gcc hello.c

C:\tmp>a.exe
hello, world!

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[Roland Schwarz]

Greg Chicares wrote:
> What version of ms windows are you using? Is it "vista"?
No, XP. (32 bit)

> Not reproduced here with ms windows "xp":
>
> C:\tmp>PATH ''
>
> C:\tmp>PATH
> PATH=''
>
> C:\tmp>\cygwin\MinGW-20070825-sjlj\bin\gcc -dumpversion
> 4.2.1-sjlj
>
> C:\tmp>\cygwin\MinGW-20070825-sjlj\bin\gcc hello.c
>
> C:\tmp>a.exe
> hello, world!

Hmm, I am trying to compile c++... and this is what I get:

C:\TMP> PATH=C:\Windows;C:\Windows\system32

C:\TMP> C:\Programme\mingw\bin\g++-sjlj hello.cpp
g++-sjlj: CreateProcess: No such file or directory

C:\TMP>

But the above works if I put the following to PATH:
PATH=C:\Windows;C:\Windows\system32;C:\Programme\mingw\bin

Any ideas?


--
_________________________________________
  _  _  | Roland Schwarz
 |_)(_  | aka. speedsnail
 | \__) | mailto:roland.schwarz@...
________| http://www.blackspace.at

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[JonY-3]

Roland Schwarz wrote:

>
> JonY wrote:
>> Hi,
>> strangely, mine works, and I don't have them in path either.
>>
>> Try adding -v to the command line. There should be clues there.
>
> Already did so. Before I discovered the behaviour I had the cygwin
> in my PATH. The as was picked up from there.
>
> Can you try with an (almost) empty PATH?
> Say just C:\mingw-4.2.1\bin;C:\Windows;C:\Windows\system32
> in it?
>
>

Hi,

I never had MinGW bin directory in my path before.

"echo main(){}|C:\MingW\bin\gcc -xc - && .\a.exe" works fine here.

I think there was an issue with the precompiled gcc 4 from sourceforge
downloads trying to pick up the back end drivers hard coded at
C:\MingW\libexec\, but that doesn't seem to be the case.

Can you use -v and determine what g++ is failing to start?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[Roland Schwarz]

Roland Schwarz wrote:

> Hmm, I am trying to compile c++... and this is what I get:
>
> C:\TMP> PATH=C:\Windows;C:\Windows\system32
>
> C:\TMP> C:\Programme\mingw\bin\g++-sjlj hello.cpp
> g++-sjlj: CreateProcess: No such file or directory
>
> C:\TMP>
>
> But the above works if I put the following to PATH:
> PATH=C:\Windows;C:\Windows\system32;C:\Programme\mingw\bin
>
> Any ideas?

The same is true for *.c for me :-(

What could I am be doing wrong?

I am using the technology preview pre-builts from source-forge.

Is this not a good idea? Should I try to build it myself?

--
_________________________________________
  _  _  | Roland Schwarz
 |_)(_  | aka. speedsnail
 | \__) | mailto:roland.schwarz@...
________| http://www.blackspace.at

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[Roland Schwarz]

JonY wrote:
> I think there was an issue with the precompiled gcc 4 from sourceforge
> downloads trying to pick up the back end drivers hard coded at
> C:\MingW\libexec\, but that doesn't seem to be the case.

Ah, I see. I am using just this download.

> Can you use -v and determine what g++ is failing to start?

as
is the last I can see before the error.

--
_________________________________________
  _  _  | Roland Schwarz
 |_)(_  | aka. speedsnail
 | \__) | mailto:roland.schwarz@...
________| http://www.blackspace.at

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[John E. / TDM]

Roland Schwarz wrote:
> With the mingw 3.4.5 release it was possible to invoke
> the compiler just by calling with an absolute path without
> the need to set up the path variable before.
>
> This is not true anymore for 4.2.1. I get a CreateProcess:
> No such file or directory error message instead.
> Has this been changed intentionally?

I can confirm this behavior.

MinGW's release of GCC 3.4.5 contains a large amount of local patching, some
of which I believe addresses issues like this of finding tools relative to
the driver executables. If you add "-v" to the command line, I expect you'll
see that the error message immediately follows a call to "as" (the
assembler). I imagine that as most of the local patches were ported to the
mainline sources, this small part didn't quite survive intact.

Looking at the output of `path-to-mingw\gcc.exe -print-search-dirs`, it
should be fairly obvious what's happening. For the programs search
directories, there is no path corresponding to the root "bin" directory,
which is where your binutils executables live. There is, however, a path
corresponding to "path-to-mingw\mingw32\bin", which is an alternate location
for the binutils tools. For a workaround, you can try copying the binutils
executables there. (Depending on which binutils release you have, there may
already be some empty files there -- I have seen this packaging bug with the
2.18.50 release.)

Cheers,
John E. / TDM


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[keithmarshall]

On Sunday 23 March 2008 16:38, Roland Schwarz wrote:

> > I think there was an issue with the precompiled gcc 4 from
> > sourceforge downloads trying to pick up the back end drivers hard
> > coded at C:\MingW\libexec\, but that doesn't seem to be the case.
>
> Ah, I see. I am using just this download.
>
> > Can you use -v and determine what g++ is failing to start?
>
> as
> is the last I can see before the error.

Have you installed binutils?  And mingw-runtime and w32api?  All in the
same prefix as the 4.2.1 compiler?

I don't recall reports of an issue with `C:/mingw' being hardcoded, but
the entire tool chain needs to located relative to the compiler driver
itself, so with that in `C:/mingw-4.2.1/bin', then the remainder of the
tool chain *must* also be installed into the `C:/mingw-4.2.1' prefix.

Regards,
Keith.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[Roland Schwarz]

Keith Marshall wrote:
> Have you installed binutils?

Yes.

> And mingw-runtime

Yes.

> and w32api?

Yes.

> All in the
> same prefix as the 4.2.1 compiler?

Yes.

>
> I don't recall reports of an issue with `C:/mingw' being hardcoded, but
> the entire tool chain needs to located relative to the compiler driver
> itself, so with that in `C:/mingw-4.2.1/bin', then the remainder of the
> tool chain *must* also be installed into the `C:/mingw-4.2.1' prefix.

Have you seen the post from:
John E. / TDM tdragon@... ?

I used his idea of the work-around. I created a symlinked directory of
the bin like so:

CD path-to-mingw
MKDIR mingw32
CD mingw32
LINKD bin path-to-mingw\bin

This works as John said. The binutil tools now are correctly picked up.

So it look like it simply would be necessary to add the bin dir to the
searched directories. Hopefully someone in charge of this won't forget
about ....

Thank you, it works for me now :-)


--
_________________________________________
  _  _  | Roland Schwarz
 |_)(_  | aka. speedsnail
 | \__) | mailto:roland.schwarz@...
________| http://www.blackspace.at

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[JonY-3]

Roland Schwarz wrote:

>> I don't recall reports of an issue with `C:/mingw' being hardcoded, but
>> the entire tool chain needs to located relative to the compiler driver
>> itself, so with that in `C:/mingw-4.2.1/bin', then the remainder of the
>> tool chain *must* also be installed into the `C:/mingw-4.2.1' prefix.
>
> Have you seen the post from:
> John E. / TDM tdragon@... ?
>
> I used his idea of the work-around. I created a symlinked directory of
> the bin like so:
>
> CD path-to-mingw
> MKDIR mingw32
> CD mingw32
> LINKD bin path-to-mingw\bin
>
> This works as John said. The binutil tools now are correctly picked up.
>
> So it look like it simply would be necessary to add the bin dir to the
> searched directories. Hopefully someone in charge of this won't forget
> about ....
>
> Thank you, it works for me now :-)
>
>

Hi,
It seems this is the hard code path problem, sort of anyway. I did a bit
of tests and was able to reproduce Roland's problem.

It looks as if the precompiled gcc was looking for binutils at
<drive>:\MinGW\bin, where drive is the drive letter gcc is residing on.
It should have been using relative paths. Placing a mingw directory with
binutils made as.exe work again.

I had a quick looked around gcc's code but wasn't able to determine how
gcc calls support programs. Any ideas?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[John E. / TDM]

JonY wrote:
> I had a quick looked around gcc's code but wasn't able to determine how
> gcc calls support programs. Any ideas?

See process_command() in gcc/gcc.c, starting after line 3939 in the 4.2.1-2
sources.

-John E. / TDM


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[Danny Smith]

> I can confirm this behavior.
>
> MinGW's release of GCC 3.4.5 contains a large amount of local
> patching, some
> of which I believe addresses issues like this of finding
> tools relative to
> the driver executables. If you add "-v" to the command line,
> I expect you'll
> see that the error message immediately follows a call to "as" (the
> assembler). I imagine that as most of the local patches were
> ported to the
> mainline sources, this small part didn't quite survive intact.

You assume too much.  There were no local patches relating to this.  

>
> Looking at the output of `path-to-mingw\gcc.exe
> -print-search-dirs`, it
> should be fairly obvious what's happening. For the programs search
> directories, there is no path corresponding to the root "bin"
> directory,
> which is where your binutils executables live. There is,
> however, a path
> corresponding to "path-to-mingw\mingw32\bin", which is an
> alternate location
> for the binutils tools.

This is not the alternate locatiion.  This is the first place the compuiler looks.
That is where binitils package is supposed to install them.


Danny


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[John E. / TDM]

Danny Smith wrote:

>> MinGW's release of GCC 3.4.5 contains a large amount of local
>> patching, some
>> of which I believe addresses issues like this of finding
>> tools relative to
>> the driver executables. If you add "-v" to the command line,
>> I expect you'll
>> see that the error message immediately follows a call to "as" (the
>> assembler). I imagine that as most of the local patches were
>> ported to the
>> mainline sources, this small part didn't quite survive intact.
>
> You assume too much.  There were no local patches relating to this.

Oops, my mistake.

>
>>
>> Looking at the output of `path-to-mingw\gcc.exe
>> -print-search-dirs`, it
>> should be fairly obvious what's happening. For the programs search
>> directories, there is no path corresponding to the root "bin"
>> directory,
>> which is where your binutils executables live. There is,
>> however, a path
>> corresponding to "path-to-mingw\mingw32\bin", which is an
>> alternate location
>> for the binutils tools.
>
> This is not the alternate locatiion.  This is the first place the
> compuiler looks.
> That is where binitils package is supposed to install them.

That's good to know. Does this indicate a packaging bug in the binutils
2.18.50 tech preview, since they were built with a different target triplet
(i686-pc-mingw32)? If not, I think it should at least merit a warning to the
effect of "since this build uses a newer target triplet, you have to have
the bin directory in your PATH".

Thanks,
-John E. / TDM


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[Earnie]

Quoting "John E. / TDM" <tdragon@...>:

>
> That's good to know. Does this indicate a packaging bug in the binutils
> 2.18.50 tech preview, since they were built with a different target triplet
> (i686-pc-mingw32)? If not, I think it should at least merit a warning to the
> effect of "since this build uses a newer target triplet, you have to have
> the bin directory in your PATH".
>

I thought the target was supposed to be stated without the triplet,
meaning --target=mingw32, for the distributed binaries since i686-pc
has little relevance to MinGW.

Earnie

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[JonY-3]

Earnie Boyd wrote:

> Quoting "John E. / TDM" <tdragon@...>:
>
>> That's good to know. Does this indicate a packaging bug in the binutils
>> 2.18.50 tech preview, since they were built with a different target triplet
>> (i686-pc-mingw32)? If not, I think it should at least merit a warning to the
>> effect of "since this build uses a newer target triplet, you have to have
>> the bin directory in your PATH".
>>
>
> I thought the target was supposed to be stated without the triplet,
> meaning --target=mingw32, for the distributed binaries since i686-pc
> has little relevance to MinGW.
>
> Earnie
>

Hi,

I noticed that some packages using autotools which would fail when the
mingw provided gcc 3.4.5 which was targeted at mingw32 and a newer user
built binutils which was targeted at i686-pc-mingw32 was used. It was
looking for the ld linker in the wrong place.

The newer binutils executables would resides in /mingw/bin and
/mingw/i686-pc-mingw32. The problem only happens when /mingw/mingw32
containing the older binutils was removed.

Problem fixed by using junction points to link mingw32 and
i686-pc-mingw32 together.

I'm sure its not gcc's fault. Gcc 3.4.5 compiles even after removing the
mingw32 directory. Its a minor autotools annoyance.

I can't think of which package using autotools had this problem, it was
quite sometime ago. Maybe they even fixed it by now.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[JonY-3]

JonY wrote:

> Earnie Boyd wrote:
>> Quoting "John E. / TDM" <tdragon@...>:
>>
>>> That's good to know. Does this indicate a packaging bug in the binutils
>>> 2.18.50 tech preview, since they were built with a different target
>>> triplet
>>> (i686-pc-mingw32)? If not, I think it should at least merit a warning
>>> to the
>>> effect of "since this build uses a newer target triplet, you have to
>>> have
>>> the bin directory in your PATH".
>>>
>>
>> I thought the target was supposed to be stated without the triplet,
>> meaning --target=mingw32, for the distributed binaries since i686-pc
>> has little relevance to MinGW.
>>
>> Earnie
>>
>
> Hi,
>
> I noticed that some packages using autotools which would fail when the
> mingw provided gcc 3.4.5 which was targeted at mingw32 and a newer user
> built binutils which was targeted at i686-pc-mingw32 was used. It was
> looking for the ld linker in the wrong place.
>
> The newer binutils executables would resides in /mingw/bin and
> /mingw/i686-pc-mingw32. The problem only happens when /mingw/mingw32
> containing the older binutils was removed.
>
> Problem fixed by using junction points to link mingw32 and
> i686-pc-mingw32 together.
>
> I'm sure its not gcc's fault. Gcc 3.4.5 compiles even after removing the
> mingw32 directory. Its a minor autotools annoyance.
>
> I can't think of which package using autotools had this problem, it was
> quite sometime ago. Maybe they even fixed it by now.
>

Oops, forgot to mention problem occurs when user ran ./configure.
configure had trouble finding the linker.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[keithmarshall]

Summarising the follow-up discussion, and taking the opportunity to add
my own two pennyworth:--

On Sunday 23 March 2008 12:45, Roland Schwarz wrote:
> With the mingw 3.4.5 release it was possible to invoke
> the compiler just by calling with an absolute path without
> the need to set up the path variable before.
>
> This is not true anymore for 4.2.1. I get a CreateProcess:
> No such file or directory error message instead.
> Has this been changed intentionally?

No.  Assuming that you are using one of our pre-built binary packages
for binutils-2.18.50, the follow-up discussion suggests that this is an
inadvertent packaging bug; thanks for alerting us.

On Sunday 23 March 2008 16:47, John E. / TDM wrote:

> Looking at the output of `path-to-mingw\gcc.exe -print-search-dirs`,
> it should be fairly obvious what's happening. For the programs search
> directories, there is no path corresponding to the root "bin"
> directory, which is where your binutils executables live. There is,
> however, a path corresponding to "path-to-mingw\mingw32\bin", which
> is an alternate location for the binutils tools. For a workaround,
> you can try copying the binutils executables there. (Depending on
> which binutils release you have, there may already be some empty
> files there -- I have seen this packaging bug with the 2.18.50
> release.)

On Monday 24 March 2008 01:07, Danny Smith wrote:
> [path-to-mingw\mingw32\bin] is not the alternate location.  This is
> the first place the compuiler looks. That is where binutils package is
> supposed to install them.

On Monday 24 March 2008 02:48, John E. / TDM wrote:
> That's good to know.  Does this indicate a packaging bug in the
> binutils 2.18.50 tech preview, since they were built with a different
> target triplet (i686-pc-mingw32)?

Yes.  I do not want to point any "finger of blame", for witch hunts
serve no useful purpose.  The underlying cause of the problem lies in
the complete absence of any agreed and formally documented policy on
how the MinGW packages should be prepared for release; for that, the
project team, as a whole, is collectively responsible.

> If not, I think it should at least merit a warning to the effect
> of "since this build uses a newer target triplet, you have to have the
> bin directory in your PATH".

It *is* a packaging bug.  For those afflicted by it, this is a possible
workaround, although perhaps not the most effective one.

On Monday 24 March 2008 12:12, JonY wrote:
> I noticed that some packages using autotools which would fail when
> the mingw provided gcc 3.4.5 which was targeted at mingw32 and a
> newer user built binutils which was targeted at i686-pc-mingw32 was
> used. It was looking for the ld linker in the wrong place.

As Danny pointed out, the correct installation path, as *he* specified
it for his MinGW-GCC builds is /path/to/mingw/mingw32/{bin,lib}; if we
accept that as the standard, (and it seems reasonable, and as good as
any to me), then...

> The newer binutils executables would reside in /mingw/bin and
> /mingw/i686-pc-mingw32. The problem only happens when /mingw/mingw32
> containing the older binutils was removed.

the implicit `i686-pc-mingw32' target specification used when building
the binutils-1.18.50 binary package is only the apparent cause of the
packaging bug; the real underlying cause is lack of an appropriately
documented packaging methodology.

The reason this didn't show up, until you removed the older binutils
from /path/to/mingw/mingw32/{bin,lib} was that GCC was actually *using*
these older tools; you may have thought you had installed the newer
binutils, but you were never using it.

> Problem fixed by using junction points to link mingw32 and
> i686-pc-mingw32 together.

This is another possible workaround, but I wouldn't classify it as
a "fix"; the only ultimately acceptable "fix" is to rebuild the binary
package, with the appropriately agreed target specification, repackage
and replace the defective binary release tarballs on the SF download
site, and mirrors.

For those afflicted by this bug, a further possible workaround would be
to physically *move* everything from /path/to/i686-pc-mingw32/{bin,lib}
into the corresponding /path/to/mingw/mingw32/{bin,lib} trees, in place
of any similarly named component files which are already there; of the
three workarounds suggested, this would be my preferred choice, as I
would expect it to restore everything to the state it should be in, to
conform with Danny's previous de-facto build standard.

On Monday 24 March 2008 11:51, Earnie Boyd wrote:
> I thought the target was supposed to be stated without the triplet,
> meaning --target=mingw32, for the distributed binaries since i686-pc
> has little relevance to MinGW.

I agree that `i686-pc', (as such, or with any other CPU designation),
has little relevance for MinGW; formalising the de-facto use of just
`mingw32' here makes sense to me.

It does seem somehow anomalous to be required to specify *any* form of
`--target=target_alias', for self-hosted (native) builds, or even of
crossed-native builds, of any package; indeed, it would be unnecessary
for building of the entire tool chain as a single integrated package.  
In the particular case of MinGW, however, it *is* necessary, to allow
for mixing and matching of component packages at different release
points, and from different maintainers.  This particular problem has
arisen because the binutils-2.18.50 tech preview has been built with no
`--target=target_alias' specified, on an i686 host, so target_alias has
been implicitly determined, by running config.guess, and the resultant
`i686-pc-mingw32' does not conform to the de-facto mingw32 standard.

There is a lesson to be learnt here; let's not ignore it.  We should
take this discussion to the developers' list, where we formally agree,
and document, a standard procedure for building MinGW packages for
public release, so that future maintainers can understand the reasons
for, and continue to follow, the standards in use today.

Regards,
Keith.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

[NightStrike]

On 3/25/08, Keith Marshall <keithmarshall@...> wrote:
> > The newer binutils executables would reside in /mingw/bin and
> > /mingw/i686-pc-mingw32. The problem only happens when /mingw/mingw32
> > containing the older binutils was removed.
>
> the implicit `i686-pc-mingw32' target specification used when building
> the binutils-1.18.50 binary package is only the apparent cause of the
> packaging bug; the real underlying cause is lack of an appropriately
> documented packaging methodology.

> > Problem fixed by using junction points to link mingw32 and
> > i686-pc-mingw32 together.
>
> This is another possible workaround, but I wouldn't classify it as
> a "fix"; the only ultimately acceptable "fix" is to rebuild the binary
> package, with the appropriately agreed target specification, repackage
> and replace the defective binary release tarballs on the SF download
> site, and mirrors.
> On Monday 24 March 2008 11:51, Earnie Boyd wrote:
> > I thought the target was supposed to be stated without the triplet,
> > meaning --target=mingw32, for the distributed binaries since i686-pc
> > has little relevance to MinGW.
>
> I agree that `i686-pc', (as such, or with any other CPU designation),
> has little relevance for MinGW; formalising the de-facto use of just
> `mingw32' here makes sense to me.

If you want to be able to have x86_64 support merge back in to mingw,
then supporting the CPU designation is advantageous.

To that end, supporting the gnu standard canonicalization fully is
advantageous.  With the way I build things, I can have both
i686-pc-mingw and x86_64-pc-mingw targetted compilers installed in the
same root directory structure.  However, the requirement of the lone
"mingw32" directory makes that difficult.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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