mingw-users

[Mingw-users] bison 3.0.2 and m4sugar.m4

[Werner L. <wl...@gn...>]

Folks,


how do I correctly compile bison 3.0.2 with mingw?

The incantation

  ./configure ac_cv_func__set_invalid_parameter_handler=no
  make
  make install

works without glitches, however, calling bison (within the msys shell)
gives me

  $ bison myfile.y
  ...\msys\1.0\local\bin\bison.exe: \
    /usr/local/share/bison/m4sugar/m4sugar.m4: \
    cannot open: No such file or directory

I tried a workaround mentioned in the web, but it still fails:

  $ BISON_PKGDATADIR=.../msys/1.0/local/share/bison \
    bison myfile.y
  ...\msys\1.0\local\bin\bison.exe: \
    m4 subprocess failed: No such file or directory 

(I have a working m4.exe of course)

What is the cause for that, and how can I fix it?  Are there special
parameters necessary for the configure script?  I see that problems
with m4sugar.m4 are present since 10(!) years, and I really wonder why
we still have to struggle with that...


    Werner

Re: [Mingw-users] bison 3.0.2 and m4sugar.m4

[Eli Z. <el...@gn...>]

> Date: Sun, 05 Oct 2014 10:22:35 +0200 (CEST)
> From: Werner LEMBERG <wl...@gn...>
> 
>   $ bison myfile.y
>   ...\msys\1.0\local\bin\bison.exe: \
>     /usr/local/share/bison/m4sugar/m4sugar.m4: \
>     cannot open: No such file or directory
> 
> I tried a workaround mentioned in the web, but it still fails:
> 
>   $ BISON_PKGDATADIR=.../msys/1.0/local/share/bison \
>     bison myfile.y
>   ...\msys\1.0\local\bin\bison.exe: \
>     m4 subprocess failed: No such file or directory 
> 
> (I have a working m4.exe of course)
> 
> What is the cause for that, and how can I fix it?

Don't install MinGW programs inside the MSYS tree.  MinGW programs
don't understand the MSYS mounts (which maps /usr/local to some place
on your system).

Re: [Mingw-users] bison 3.0.2 and m4sugar.m4

[Werner L. <wl...@gn...>]

>>   $ bison myfile.y
>>   ...\msys\1.0\local\bin\bison.exe: \
>>     /usr/local/share/bison/m4sugar/m4sugar.m4: \
>>     cannot open: No such file or directory
>> 
>> I tried a workaround mentioned in the web, but it still fails:
>> 
>>   $ BISON_PKGDATADIR=.../msys/1.0/local/share/bison \
>>     bison myfile.y
>>   ...\msys\1.0\local\bin\bison.exe: \
>>     m4 subprocess failed: No such file or directory 
>> 
>> (I have a working m4.exe of course)
>> 
>> What is the cause for that, and how can I fix it?
> 
> Don't install MinGW programs inside the MSYS tree.  MinGW programs
> don't understand the MSYS mounts (which maps /usr/local to some place
> on your system).

Essentially you say that for *all* packages I should set `--prefix' to
a non-msys-mounted directory, right?

OK, tried that for bison.  Executing it within the msys shell, it
finds m4sugar.m4.  However, I still get

  m4 subprocess failed: No such file or directory 

So I tried to install m4 also into my new prefix.  And bison still
doesn't work, aborting with the same error!  This is extremely
frustrating.

Note that I actually need `bison' only to be run within msys, as an
update to version 2.4.2, which is too old for my purposes.  For this
special situation, I would thus like to build an `msys-bison' program
in `/usr/local'.  How can I build that?


    Werner

Re: [Mingw-users] bison 3.0.2 and m4sugar.m4

[Eli Z. <el...@gn...>]

> Date: Sun, 05 Oct 2014 23:16:25 +0200 (CEST)
> From: Werner LEMBERG <wl...@gn...>
> 
> 
> >>   $ bison myfile.y
> >>   ...\msys\1.0\local\bin\bison.exe: \
> >>     /usr/local/share/bison/m4sugar/m4sugar.m4: \
> >>     cannot open: No such file or directory
> >> 
> >> I tried a workaround mentioned in the web, but it still fails:
> >> 
> >>   $ BISON_PKGDATADIR=.../msys/1.0/local/share/bison \
> >>     bison myfile.y
> >>   ...\msys\1.0\local\bin\bison.exe: \
> >>     m4 subprocess failed: No such file or directory 
> >> 
> >> (I have a working m4.exe of course)
> >> 
> >> What is the cause for that, and how can I fix it?
> > 
> > Don't install MinGW programs inside the MSYS tree.  MinGW programs
> > don't understand the MSYS mounts (which maps /usr/local to some place
> > on your system).
> 
> Essentially you say that for *all* packages I should set `--prefix' to
> a non-msys-mounted directory, right?

That too, but it's a separate issue.  Bison should work regardless of
its configure-time --prefix setting.

What I say is you should have the bison.exe binary outside of the MSYS
tree.

> OK, tried that for bison.  Executing it within the msys shell, it
> finds m4sugar.m4.  However, I still get
> 
>   m4 subprocess failed: No such file or directory 
> 
> So I tried to install m4 also into my new prefix.  And bison still
> doesn't work, aborting with the same error!  This is extremely
> frustrating.

That's probably a separate problem.  Do you have m4.exe installed, and
is that m4.exe a MinGW program or an MSYS program?  It should be a
MinGW program.

> Note that I actually need `bison' only to be run within msys, as an
> update to version 2.4.2, which is too old for my purposes.  For this
> special situation, I would thus like to build an `msys-bison' program
> in `/usr/local'.  How can I build that?

If you need an MSYS bison, and there's no newer version on the MinGW
download site, you need to build it.  I never build an MSYS program,
but AFAIU you will need an MSYS development environment, available
from the download site.

Btw, what exactly is wrong with the version of MSYS bison 2.4.2 that
makes it "too old" for your purposes?

Re: [Mingw-users] bison 3.0.2 and m4sugar.m4

[Werner L. <wl...@gn...>]

>> Essentially you say that for *all* packages I should set `--prefix'
>> to a non-msys-mounted directory, right?
>
> That too, but it's a separate issue.  Bison should work regardless of
> its configure-time --prefix setting.

How shall this work out of the box?  If you build with msys, the
default prefix `/usr/local' definitely points into msys.  If I move
bison out of the tree, the m4 files in the `/usr/local/' hierarchy are
no longer found...  So I have to set the undocumented
`BISON_PKGDATADIR' environment variable to circumvent this...

> Do you have m4.exe installed, and is that m4.exe a MinGW program or
> an MSYS program?  It should be a MinGW program.

Now I have two m4.exe programs.  The first comes with msys and fails
for my non-msys bison.  Then I've rebuilt m4.exe with the standard
`./configure; make; make install' incantation into a prefix outside of
msys (the same as with my new bison program for convenience).  This
makes it a MinGW program, right?  Finally, I've rebuilt bison,
assuring that bison's `configure' program really uses the newly built
m4 executable.  After adjusting PATH to make the new bison and m4 be
found first, it still fails in both the `cmd' and `msys' shell.

> If you need an MSYS bison, and there's no newer version on the MinGW
> download site, you need to build it.  I never build an MSYS program,
> but AFAIU you will need an MSYS development environment, available
> from the download site.

Sigh.  I guess I'm out of patience now.  The whole issue has cost me
more than two days, with zero results.  Given that MinGW64 comes with
a recent bison version, I will try this route now.

> Btw, what exactly is wrong with the version of MSYS bison 2.4.2 that
> makes it "too old" for your purposes?

I need version 2.5 or newer because I use the very convenient feature
of named references.


    Werner

Re: [Mingw-users] bison 3.0.2 and m4sugar.m4

[Eli Z. <el...@gn...>]

> Date: Mon, 06 Oct 2014 07:37:46 +0200 (CEST)
> Cc: min...@li...
> From: Werner LEMBERG <wl...@gn...>
> 
> 
> > Bison should work regardless of its configure-time --prefix
> > setting.
> 
> How shall this work out of the box?

I said "should".  In this case, the original Bison code doesn't
provide such a feature, so I needed to add it in my own build (using
GetModuleFileName).  Sorry, I should have been clearer on that.

> If you build with msys, the default prefix `/usr/local' definitely
> points into msys.

I never build on Windows without an explicit --prefix argument.  It is
not useful to do otherwise, as the result will be at best unreliable
and at worst simply won't work.  /usr/local is not an absolute file
name on Windows, and even if it happens to exist on some drive, it
will not be what you intended.

> If I move bison out of the tree, the m4 files in the `/usr/local/'
> hierarchy are no longer found...  So I have to set the undocumented
> `BISON_PKGDATADIR' environment variable to circumvent this...

Not if the executable is "relocatable", i.e. can look for the files
relative to its own location.

> > Do you have m4.exe installed, and is that m4.exe a MinGW program or
> > an MSYS program?  It should be a MinGW program.
> 
> Now I have two m4.exe programs.  The first comes with msys and fails
> for my non-msys bison.  Then I've rebuilt m4.exe with the standard
> `./configure; make; make install' incantation into a prefix outside of
> msys (the same as with my new bison program for convenience).  This
> makes it a MinGW program, right?

If you compiled with MinGW GCC, then yes.

> Finally, I've rebuilt bison, assuring that bison's `configure'
> program really uses the newly built m4 executable.  After adjusting
> PATH to make the new bison and m4 be found first, it still fails in
> both the `cmd' and `msys' shell.

Ah, that rings a bell.  Do you have a line in your config.h saying
something like

  #define M4 "/d/foo/bar/m4"

If so, that's the culprit: the configure script records that file name
in the MSYS format, and then bison tries to use it, and fails.

I resolved this by forcing the M4 value at configure time:

   M4=m4.exe ./configure ...

This kills 2 birds: it solves the above problem, and it causes
bison.exe to look for m4.exe on PATH, rather than insist on finding it
in some specific place -- again, a boon if you move the binary.

> > If you need an MSYS bison, and there's no newer version on the MinGW
> > download site, you need to build it.  I never build an MSYS program,
> > but AFAIU you will need an MSYS development environment, available
> > from the download site.
> 
> Sigh.  I guess I'm out of patience now.  The whole issue has cost me
> more than two days, with zero results.

I'm sorry to hear that.  I presumed that you are working with a
debugger to solve these issues, because then you'd see immediately the
reason for the above problem.

There are a couple of other issues with Bison 3.0.2 on Windows (yes, I
built it just today, so now I know ;-).  If you still want to build
your own, I can send you the patches.

Re: [Mingw-users] bison 3.0.2 and m4sugar.m4

[Werner L. <wl...@gn...>]

>> If you build with msys, the default prefix `/usr/local' definitely
>> points into msys.
>
> I never build on Windows without an explicit --prefix argument.  It
> is not useful to do otherwise, as the result will be at best
> unreliable and at worst simply won't work.  /usr/local is not an
> absolute file name on Windows, and even if it happens to exist on
> some drive, it will not be what you intended.

Now I know, thanks.  It's not trivial to grasp all those intricate
details of the differences between msys and MinGW.

>> If I move bison out of the tree, the m4 files in the `/usr/local/'
>> hierarchy are no longer found...  So I have to set the undocumented
>> `BISON_PKGDATADIR' environment variable to circumvent this...
>
> Not if the executable is "relocatable", i.e. can look for the files
> relative to its own location.

Indeed.  However, I guess that by default bison 3.0.2 doesn't do
this...

> Ah, that rings a bell.  Do you have a line in your config.h saying
> something like
>
>   #define M4 "/d/foo/bar/m4"
>
> [...]

I will be able to check that in two days.

> I presumed that you are working with a debugger to solve these
> issues, because then you'd see immediately the reason for the above
> problem.

Maybe next time...  

> There are a couple of other issues with Bison 3.0.2 on Windows (yes,
> I built it just today, so now I know ;-).  If you still want to
> build your own, I can send you the patches.

Please do so.  It sounds like you've solved the problem; this would
then simplify everything :-)


    Werner

Re: [Mingw-users] bison 3.0.2 and m4sugar.m4

[Eli Z. <el...@gn...>]

> Date: Mon, 06 Oct 2014 07:40:42 +0200 (CEST)
> Cc: min...@li...
> From: Werner LEMBERG <wl...@gn...>
> 
> And thanks a lot for your help, Eli!

You are welcome.

> It's a pity that Earnie has disappeared completely, and that mingw
> fails behind more and more due to lack of manpower.

I don't understand what this has to do with the issue at hand.  AFAIK,
the MinGW project never offered a MinGW port of bison.  The only
native port I know of that is publicly available is an ancient port in
the (now deceased) GnuWin32 project.

Re: [Mingw-users] bison 3.0.2 and m4sugar.m4

[Werner L. <wl...@gn...>]

> AFAIK, the MinGW project never offered a MinGW port of bison.

>From the README in

  https://sourceforge.net/projects/mingw/files/MSYS/Extension/bison/bison-2.4.2-1/

  The packages within the MSYS/Extension directory are supported by
  the MinGW team, and provide useful facilities not required for a
  basic MSYS installation.

This is what I would like to have updated.  I suspect that with `MinGW
port' you mean a bison executable to be run outside of the msys
environment.  As mentioned earlier, I don't really need this since I
configure and compile my package within an msys shell.


    Werner

Re: [Mingw-users] bison 3.0.2 and m4sugar.m4

[Eli Z. <el...@gn...>]

> Date: Mon, 06 Oct 2014 17:40:35 +0200 (CEST)
> Cc: min...@li...
> From: Werner LEMBERG <wl...@gn...>
> 
> 
> > AFAIK, the MinGW project never offered a MinGW port of bison.
> 
> >From the README in
> 
>   https://sourceforge.net/projects/mingw/files/MSYS/Extension/bison/bison-2.4.2-1/
> 
>   The packages within the MSYS/Extension directory are supported by
>   the MinGW team, and provide useful facilities not required for a
>   basic MSYS installation.
> 
> This is what I would like to have updated.

That's an MSYS Bison, not a MinGW (a.k.a. "native") Bison.  I don't
see why would you need an MSYS Bison, unless you are building the MSYS
toolchain.

> I suspect that with `MinGW port' you mean a bison executable to be
> run outside of the msys environment.

Not "outside of MSYS environment", but rather an executable that
doesn't use any of the MSYS DLLs, including msys-1.0.dll, the Cygwin
DLL in disguise.

IOW, I mean a native Windows application that uses the native Windows
runtime, and nothing else.

> As mentioned earlier, I don't really need this since I configure and
> compile my package within an msys shell.

That's a serious confusion, but I won't explain why unless you ask me
to.  If you are happy running MSYS Bison, it's fine by me.

Re: [Mingw-users] bison 3.0.2 and m4sugar.m4

[Werner L. <wl...@gn...>]

> That's an MSYS Bison, not a MinGW (a.k.a. "native") Bison.  I don't
> see why would you need an MSYS Bison, unless you are building the
> MSYS toolchain.

Hmm.

>> As mentioned earlier, I don't really need this since I configure
>> and compile my package within an msys shell.
> 
> That's a serious confusion, but I won't explain why unless you ask
> me to.  If you are happy running MSYS Bison, it's fine by me.

Well, please explain.  I always thought that the msys binaries are
(mainly?) used for executing configure scripts or Makefiles within the
msys shell.  In case I'm wrong, I really wonder why executing `bison'
on the msys prompt works at all...


    Werner

Re: [Mingw-users] bison 3.0.2 and m4sugar.m4

[Eli Z. <el...@gn...>]

> Date: Mon, 06 Oct 2014 19:12:59 +0200 (CEST)
> Cc: min...@li...
> From: Werner LEMBERG <wl...@gn...>
> 
> 
> >> As mentioned earlier, I don't really need this since I configure
> >> and compile my package within an msys shell.
> > 
> > That's a serious confusion, but I won't explain why unless you ask
> > me to.  If you are happy running MSYS Bison, it's fine by me.
> 
> Well, please explain.  I always thought that the msys binaries are
> (mainly?) used for executing configure scripts or Makefiles within the
> msys shell.

In a nutshell, you don't need an MSYS bison for the same reason you
don't need an MSYS GCC -- these tools are for _producing_ programs,
not _configuring_ them (Bash, Coreutils, Grep, etc.) and guiding their
build (Make).  MSYS was developed to provide the latter functionality,
so I suggest to use it as such.

I know some people disagree -- but those are usually the same people
who use the MSYS Bash as their routine command line, for purposes that
have nothing to do with configuring and building MinGW programs.  They
simply like Bash and the rest of the Posix-like environment better.
My advice to those is to switch to Cygwin, since that's what they
really want.

> In case I'm wrong, I really wonder why executing `bison' on the msys
> prompt works at all...

Because one should be able to build the MSYS toolchain, the one needed
to compile MSYS builds of GNU tools.

Re: [Mingw-users] bison 3.0.2 and m4sugar.m4

[Werner L. <wl...@gn...>]

> Given that MinGW64 comes with a recent bison version, I will try
> this route now.

And thanks a lot for your help, Eli!  It's a pity that Earnie has
disappeared completely, and that mingw fails behind more and more due
to lack of manpower.


    Werner

Re: [Mingw-users] bison 3.0.2 and m4sugar.m4

[santhosh d. <ssa...@gm...>]

hi
        how to unsubscribe

On Mon, Oct 6, 2014 at 11:10 AM, Werner LEMBERG <wl...@gn...> wrote:
>> Given that MinGW64 comes with a recent bison version, I will try
>> this route now.
>
> And thanks a lot for your help, Eli!  It's a pity that Earnie has
> disappeared completely, and that mingw fails behind more and more due
> to lack of manpower.
>
>
>     Werner
>
> ------------------------------------------------------------------------------
> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:min...@li...?subject=unsubscribe