headers
Keith Marshall | 12 Aug 2006 17:13
Picon

Re: Problem xcompiling mingw-runtime-3.10

On Monday 24 July 2006 1:14 pm, Michael Gerdau wrote:
> During my recent tests regarding dbginfo in mingw gcc libs I realized
> I can't create a linux hosted xcompiler incorporating
> mingw-runtime-3.10

Michael,

I too am experiencing difficulties in this area, but I am seeing very 
different symptoms from those you report, and even very different 
behaviours across differing Linux host variants; perhaps Danny, or 
Chris Faylor could comment on the symptoms of failure I've observed.

I'm using your script, and I've set it up thus:

  #  Directories:--
  #
    PACKAGE_DIR=$HOME/packages/mingw-3.4.5
    BUILD_ROOT=$HOME/sandbox/mingw/build/mingw-3.4.5
    PREFIX=$HOME/sandbox/mingw/staged
  #
  #  Package Versions:--
  #
    GCC_VERSION="3.4.5-20060117-1"
    BINUTILS_VERSION="2.17.50-20060716-1"
    W32API_VERSION="3.7"
    RUNTIME_VERSION="3.10"

Now, running the script on my aged Mandrake 8.2 host, where the native 
compiler is gcc-2.96, this configuration gives me an i586-mingw32-gcc in 
$HOME/sandbox/mingw/staged, which appears to work correctly, creating
(Continue reading)

Permalink | Reply |
headers
Michael Gerdau | 12 Aug 2006 22:39
Picon
Favicon

Re: Problem xcompiling mingw-runtime-3.10

Hi Keith !

Sorry to not have reacted on your earlier mail -- I just returned
from a 2 weeks vacation this weekend and didn't manage to further
investigate prior to that.

Currently I'm still catching up with my emails...

[problems creating a mingw gcc-3.4.5 toolchain with runtime-3.10]

> I too am experiencing difficulties in this area, but I am seeing very 
> different symptoms from those you report, and even very different 
> behaviours across differing Linux host variants; perhaps Danny, or 
> Chris Faylor could comment on the symptoms of failure I've observed.

FWIW I'm on SuSE 9.3 with gcc 3.3.5-prerelease. For me it works as
long as I stick with runtime-3.9 (newest binutils and all other
components).

> Now, running the script on my aged Mandrake 8.2 host, where the native 
> compiler is gcc-2.96, this configuration gives me an i586-mingw32-gcc in 
> $HOME/sandbox/mingw/staged, which appears to work correctly, creating 
> executables which I can run under Wine.  However, `gcov' support still 
> isn't working correctly; I get a `.gcno' file from the compiler, but no 
> `.gcda' file when I run it under Wine.

Interesting.

> Running this identical script on a SUSE-10.0 host, where the native 
> compiler is gcc-4.0.2 fails to build a working i586-mingw32-gcc,
(Continue reading)

Permalink | Reply |
headers
Danny Smith | 29 Aug 2006 23:01
Picon

Re: Problem xcompiling mingw-runtime-3.10


> What I see is the test to determine the default executable 
> extension (presumably .exe) fails because the link step needs 
> crt2.o which is not yet there at this point in time -- at 
> first glance it seems like a bootstrapping problem.
> 
> Is there a way to skip over that particular test at that stage ?
> 
http://sourceware.org/ml/binutils/2006-08/msg00312.html

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Permalink | Reply |
headers
Michael Gerdau | 30 Aug 2006 08:26
Picon
Favicon

Re: Problem xcompiling mingw-runtime-3.10

> > What I see is the test to determine the default executable 
> > extension (presumably .exe) fails because the link step needs 
> > crt2.o which is not yet there at this point in time -- at 
> > first glance it seems like a bootstrapping problem.
> > 
> > Is there a way to skip over that particular test at that stage ?
> > 
> http://sourceware.org/ml/binutils/2006-08/msg00312.html

I just had a look at it on the train an AFAICS this patchset is
exactly what I've been looking for.

In other words and to answer the question D.J.Delorie asked somewhere
in the threat:
I'm all for including this patchset.

Is there anyone speaking up as MinGW maintainer on the binutils
list and and approve of it ?

Best,
Michael
--

-- 
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mgd@...
 GPG-keys available on request or at public keyserver

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
(Continue reading)

Permalink | Reply |
headers
Danny Smith | 30 Aug 2006 11:26
Picon

Re: Problem xcompiling mingw-runtime-3.10

> > http://sourceware.org/ml/binutils/2006-08/msg00312.html
> 
> I just had a look at it on the train an AFAICS this patchset 
> is exactly what I've been looking for.
> 
> In other words and to answer the question D.J.Delorie asked 
> somewhere in the threat: I'm all for including this patchset.
> 
> Is there anyone speaking up as MinGW maintainer on the 
> binutils list and and approve of it ?

I've spoken up on the concerned lists in support of this patch.  The
changes to mingw and w32api directories do not need top-level approval
but I would prefer to advocate that the whole patchset
is applied to ensure continued top-level support.

Danny

> 
> Best,
> Michael

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Permalink | Reply |
headers
Christopher Faylor | 30 Aug 2006 15:59
Favicon

Re: Problem xcompiling mingw-runtime-3.10

On Wed, Aug 30, 2006 at 09:26:16PM +1200, Danny Smith wrote:
>> > http://sourceware.org/ml/binutils/2006-08/msg00312.html
>> 
>> I just had a look at it on the train an AFAICS this patchset 
>> is exactly what I've been looking for.
>> 
>> In other words and to answer the question D.J.Delorie asked 
>> somewhere in the threat: I'm all for including this patchset.
>> 
>> Is there anyone speaking up as MinGW maintainer on the 
>> binutils list and and approve of it ?
>
>I've spoken up on the concerned lists in support of this patch.  The
>changes to mingw and w32api directories do not need top-level approval
>but I would prefer to advocate that the whole patchset
>is applied to ensure continued top-level support.

Looks like the patches are in.

FWIW, I forwarded Corinna most of the discussion from this list so she
was aware of the problem.

Does this solve all of the reported problems now?

cgf

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
(Continue reading)

Permalink | Reply |
headers
Keith Marshall | 3 Sep 2006 10:13
Picon

Re: Problem xcompiling mingw-runtime-3.10

On Wednesday 30 August 2006 2:59 pm, Christopher Faylor wrote:
[Re: Corinna Vinschen's patchset, as discussed on mingw-patches]
> >I've spoken up on the concerned lists in support of this patch.  The
> >changes to mingw and w32api directories do not need top-level approval
> >but I would prefer to advocate that the whole patchset
> >is applied to ensure continued top-level support.
>
> Looks like the patches are in.
>
> FWIW, I forwarded Corinna most of the discussion from this list so she
> was aware of the problem.

I'm coming somewhat late to this particular party.  I guess I should have 
been subscribed to mingw-patches, but wasn't; we normally discuss this 
sort of thing on mingw-dvlpr.

> Does this solve all of the reported problems now?

Seems to resolve the problem.  As I'd noted in a previous message, I'd 
independently arrived at a simplified variation on the same theme, but 
Corinna's patchset is more comprehensive.  I do think, however, that some 
simplification would be appropriate; the following is ok for MinGW, but 
would it break anything in Cygwin?

2006-09-??  Keith Marshall  <keithmarshall@...>

        * aclocal.m4 (LIB_AC_PROG_CC): Redundant macro; deleted.
        (LIB_AC_PROG_CC_GNU, LIB_AC_PROG_CXX): Likewise.

        * configure.in (LIB_AC_PROG_CC): Replaced by...
(Continue reading)

Permalink | Reply |
headers
Keith Marshall | 3 Sep 2006 12:07
Picon

Re: [RFC] Simplify MinGW canadian crosses

On Sunday 03 September 2006 9:13 am, Keith Marshall wrote:
> On Wednesday 30 August 2006 2:59 pm, Christopher Faylor wrote:
> > FWIW, I forwarded Corinna most of the discussion from this list so
> > she was aware of the problem.
>
> I'm coming somewhat late to this particular party.  I guess I should
> have been subscribed to mingw-patches, but wasn't; we normally discuss
> this sort of thing on mingw-dvlpr.

Just to add my two pennyworth...

On Tue, Aug 29, 2006 at 06:04:06PM +0200, Corinna Vinschen wrote:
> On Aug 29 11:47, Christopher Faylor wrote:
> > Btw, I agree with Daniel's suggestion of using
> > ../config/no-executables.m4 if that's possible.
> 
> I did that first, but the argument against this is that the
> mingw-runtime package, does not contain a top-level config directory.
> The source tree is supposed to be built stand-alone.  Therefore it's
> required to have a stand-alone aclocal.m4 file.
> 
> [time passes]
> 
> Or do you mean I should just add an include(../config/no-executables.m4)
> to winsup/acinclude.m4 and create the aclocal.m4 files from there?

and Daniel Jacobowitz replied: 
> If you do that it'll just emit a sinclude into aclocal.m4 anyway, won't 
> it?
(Continue reading)

Permalink | Reply |
headers
Keith Marshall | 3 Sep 2006 12:07
Picon

Re: [RFC] Simplify MinGW canadian crosses

On Sunday 03 September 2006 9:13 am, Keith Marshall wrote:
> On Wednesday 30 August 2006 2:59 pm, Christopher Faylor wrote:
> > FWIW, I forwarded Corinna most of the discussion from this list so
> > she was aware of the problem.
>
> I'm coming somewhat late to this particular party.  I guess I should
> have been subscribed to mingw-patches, but wasn't; we normally discuss
> this sort of thing on mingw-dvlpr.

Just to add my two pennyworth...

On Tue, Aug 29, 2006 at 06:04:06PM +0200, Corinna Vinschen wrote:
> On Aug 29 11:47, Christopher Faylor wrote:
> > Btw, I agree with Daniel's suggestion of using
> > ../config/no-executables.m4 if that's possible.
> 
> I did that first, but the argument against this is that the
> mingw-runtime package, does not contain a top-level config directory.
> The source tree is supposed to be built stand-alone.  Therefore it's
> required to have a stand-alone aclocal.m4 file.
> 
> [time passes]
> 
> Or do you mean I should just add an include(../config/no-executables.m4)
> to winsup/acinclude.m4 and create the aclocal.m4 files from there?

and Daniel Jacobowitz replied: 
> If you do that it'll just emit a sinclude into aclocal.m4 anyway, won't 
> it?
(Continue reading)

Permalink | Reply |
headers
Christopher Faylor | 3 Sep 2006 17:33

Re: [MinGW-patches] [RFC] Simplify MinGW canadian crosses

On Sun, Sep 03, 2006 at 11:07:27AM +0100, Keith Marshall wrote:
>Just for the record, I personally prefer to maintain aclocal.m4 by
>hand, rather than generate it using the aclocal tool--which is not an
>autoconf tool, BTW; it is provided by automake, which I utterly loathe
>and detest.  Whle aclocal may be convenient, it is also an excellent
>way to carelessly drag in needless dependencies--as an example,
>consider the GNU libiconv autoconfigury, which forces you to distribute
>config.guess, config.sub and config.rpath, together with about half a
>dozen unnecessary m4 files, along with your project, but none of these
>are essential for a basic libiconv client, and by handcrafting
>aclocal.m4, I can easily eliminate the unnecessary dependencies.  (Of
>course, it isn't the aclocal tool that is particularly at fault
>here--it is a consequence of carelessly written m4 sources in the first
>instance--but using aclocal is lazy, and tends to conceal this initial
>carelessness).

While I agree 100% about automake (I'm not a big fan of autoconf
either), I don't think that it makes sense to hand-craft aclocal.m4.
IMO, if you have a bunch of people updating aclocal.m4 in their own
idiosyncratic way, you are just asking for trouble.  If acinclude.m4
is kept relatively simple, I don't see the harm in using aclocal to
generate all of the aclocal.m4's in the winsup tree.

cgf

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
(Continue reading)

Permalink | Reply |
headers
Christopher Faylor | 3 Sep 2006 17:33

Re: [RFC] Simplify MinGW canadian crosses

On Sun, Sep 03, 2006 at 11:07:27AM +0100, Keith Marshall wrote:
>Just for the record, I personally prefer to maintain aclocal.m4 by
>hand, rather than generate it using the aclocal tool--which is not an
>autoconf tool, BTW; it is provided by automake, which I utterly loathe
>and detest.  Whle aclocal may be convenient, it is also an excellent
>way to carelessly drag in needless dependencies--as an example,
>consider the GNU libiconv autoconfigury, which forces you to distribute
>config.guess, config.sub and config.rpath, together with about half a
>dozen unnecessary m4 files, along with your project, but none of these
>are essential for a basic libiconv client, and by handcrafting
>aclocal.m4, I can easily eliminate the unnecessary dependencies.  (Of
>course, it isn't the aclocal tool that is particularly at fault
>here--it is a consequence of carelessly written m4 sources in the first
>instance--but using aclocal is lazy, and tends to conceal this initial
>carelessness).

While I agree 100% about automake (I'm not a big fan of autoconf
either), I don't think that it makes sense to hand-craft aclocal.m4.
IMO, if you have a bunch of people updating aclocal.m4 in their own
idiosyncratic way, you are just asking for trouble.  If acinclude.m4
is kept relatively simple, I don't see the harm in using aclocal to
generate all of the aclocal.m4's in the winsup tree.

cgf

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
(Continue reading)

Permalink | Reply |
headers
Pedro Alves | 30 Aug 2006 12:15
Picon
Favicon

Re: Problem xcompiling mingw-runtime-3.10

Hi guys!

(I'm not on MinGW-dvlpr, so this may not get through...)

I've ran into this problem too, while building a arm-wince-mingw32 runtime.

The way I've come around it without changing any autoconfigury, was to
create a dummy crt2.o and dummy libs (libmingw* and friends).
With these in place, when configure tries to make an a.exe to check for
the default output filename, etc, it can. Of course the a.exe wouln't
run, but that doesn't matter anyway, since we are crosscompiling, and it 
would never run.

With these dummy libs, the steps to build the cross toolchain are:

- build/install binutils
- build gcc c only (make all-gcc/install-gcc)
- run install.sh (install dummy runtime, see below)
- build mingw runtime.
- build gcc c, c++, etc.

---

$ cat crt2.s 
  .text
  .global  __EH_FRAME_BEGIN__
  .global  _CRT_MT
  .global __gthread_once
  .global abort
  .global GetCurrentThreadId
(Continue reading)

Permalink | Reply |
headers
Danny Smith | 30 Aug 2006 23:00
Picon

Re: Problem xcompiling mingw-runtime-3.10


> 
> > > http://sourceware.org/ml/binutils/2006-08/msg00312.html
> > 
> > I just had a look at it on the train an AFAICS this patchset
> > is exactly what I've been looking for.
> > 

It has been installed by Corinna.

Danny

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Permalink | Reply |
headers
Keith Marshall | 31 Aug 2006 08:04
Picon

Re: Problem xcompiling mingw-runtime-3.10

On Wednesday 30 August 2006 10:00 pm, Danny Smith wrote:
> > 
> > > > http://sourceware.org/ml/binutils/2006-08/msg00312.html
> > >
> > > I just had a look at it on the train an AFAICS this patchset
> > > is exactly what I've been looking for.
> > >
>
> It has been installed by Corinna.

I've not been able to monitor this thread, for a day or two, but I'd also 
independently tracked down the source of the configure problem, which is 
definitely due to actions performed by AC_PROC_CC, and I'd also succeeded 
in resolving it, at the autoconf level, but in a somewhat more simplistic 
fashion, (see below).

Corinna's patch has certainly cleaned up aclocal.m4 considerably, but we 
can go even further.  We do not need any of LIB_AC_PROG_CC_GNU, 
LIB_AC_PROG_CC or LIB_AC_PROG_CXX; it is sufficient to simply expand 
GCC_NO_EXECUTABLES *before* expanding the standard AC_PROG_CC, to achieve 
our objective.  In fact, for our immediate purposes it is sufficient to 
simply

  m4_define([_AC_COMPILER_EXEEXT],[])

before expanding AC_PROG_CC, but GCC_NO_EXECUTABLES is probably a more 
robust solution for long term use.

BTW, I've now got the beast to build on my Ubuntu-6.06 laptop; I needed 
to install all of `flex', `bison' and `texinfo', before `binutils' would
(Continue reading)

Permalink | Reply |
headers
Michael Gerdau | 30 Aug 2006 07:37
Picon
Favicon

Re: Problem xcompiling mingw-runtime-3.10

> > What I see is the test to determine the default executable 
> > extension (presumably .exe) fails because the link step needs 
> > crt2.o which is not yet there at this point in time -- at 
> > first glance it seems like a bootstrapping problem.
> > 
> > Is there a way to skip over that particular test at that stage ?
> > 
> http://sourceware.org/ml/binutils/2006-08/msg00312.html

Very interesting post. I'll check it out either today or tomorrow,
depending on today's schedule.

Best,
Michael
--

-- 
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mgd@...
 GPG-keys available on request or at public keyserver

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
(Continue reading)

Permalink | Reply |
headers
Keith Marshall | 13 Aug 2006 15:45
Picon

Re: Problem xcompiling mingw-runtime-3.10

Hi Michael,

Hope you enjoyed your holiday, and are fit, rested and eager to get back 
to the grindstone. :-)

On Saturday 12 August 2006 9:39 pm, Michael Gerdau wrote:
> > Danny, FWIW, the `config.log' is littered with reports of fatal
> > redefinitions of `exit(int)' throwing different exceptions; is this
> > in some way significant?  Is it just not possible to build a gcc-3.x
> > cross with a native gcc-4.x?
>
> I don't see these using a native gcc 3.3.5

AIUI, gcc-4.x is a great deal more stringent in standards enforcement 
than any gcc-3.x version ever was.  Autoconf-2.60 no longer uses `exit' 
calls in any of it's macros, presumably because of such problems.

> What I see is the test to determine the default executable extension
> (presumably .exe) fails because the link step needs crt2.o which is
> not yet there at this point in time -- at first glance it seems like
> a bootstrapping problem.
>
> Is there a way to skip over that particular test at that stage ?

No, it's a fundamental component of the test for a working compiler.  
However, since this occurs at the stage where you are now using the cross 
compiler you just built, to compile its support libraries for the foreign 
host, it should not need any of those libraries to pre-exist.  The 
standard test, for a compile with `host == build', runs a check to ensure 
that the compiler generates working executables; it should automatically
(Continue reading)

Permalink | Reply |

Gmane