[Caml-list] Building pcre-ocaml 7.0.2 on MinGW

[Caml-list] Building pcre-ocaml 7.0.2 on MinGW

[David Allsopp]

It's been a while since I refreshed my OCaml installation from 3.12.1 but
having discovered that GADTs may really be the best thing since sliced
bread, I've been upgrading all my OCaml packages on Windows.

I'd noticed when I last refreshed (pcre-ocaml 6.2.5 / pcre 8.21) that pcre
8.21 no longer built under Windows but on that occasion I was lazy and stuck
with pcre 8.12 as that did build. This time, I've managed to get pcre 8.33
and pcre-ocaml 7.0.2 compiled under MinGW (32-bit) but with some very hacky
effort required.

Wondering if anyone else has succeeded doing this and whether there are any
GNU autotools experts here who might be able to provide pointers to the
weird problem with libtool before I brave posting to the autotools list! :o)

(Background: Windows Vista VM running Cygwin 1.7.20, GCC 4.5.3)
Configured PCRE with:
./configure --prefix="C:/Dev/OCaml" --includedir="C:/Dev/OCaml/lib"
--disable-cpp --enable-utf8 --host=i686-w64-mingw32 --build=mingw32

At this point, make all will freeze (completely crashes the terminal) when
it gets to libpcre.la. The same goes for PCRE 8.13, 8.20 and 8.21. A limited
comparison of the sources suggests that the issue is with libtool. The
workaround I've used is to configure PCRE 8.12 with the same switches and
then overwrite the libtool script in PCRE 8.33 with the one generated by
PCRE 8.12's configure. PCRE 8.12 is built with autoconf 2.65 where 8.33 is
built with autoconf 2.68 (I tried installing autoconf 2.65 and regenerating
the configure script in 8.33 but that didn't work either).

Having built PCRE 8.33 and installed it, it's necessary to produce a wrapper
.cmd file for pcre-config so that ocaml setup.ml -build works for pcre-ocaml
7.0.2 as unfortunately it's now using ocamlbuild rather than make (which
could use pcre-config directly).

With both of those shims in place, it does seem to be working - but has
anyone else been trying or experienced trouble building PCRE on Windows
since version 8.12? I haven't got the first clue how to debug libtool...


David

Re: [Caml-list] Building pcre-ocaml 7.0.2 on MinGW

[Markus Mottl]

I have no experience with OCaml installations on Windows, but what
concerns the configuration of pcre-ocaml, it actually does use
pcre-config.  If the latter is not in your path, you can add the
configure flag "--with-pcre-config {full path to pcre-config}" to make
it work.

Regards,
Markus

On Wed, Jun 19, 2013 at 10:36 AM, David Allsopp <dra-news@metastack.com> wrote:
> It's been a while since I refreshed my OCaml installation from 3.12.1 but
> having discovered that GADTs may really be the best thing since sliced
> bread, I've been upgrading all my OCaml packages on Windows.
>
> I'd noticed when I last refreshed (pcre-ocaml 6.2.5 / pcre 8.21) that pcre
> 8.21 no longer built under Windows but on that occasion I was lazy and stuck
> with pcre 8.12 as that did build. This time, I've managed to get pcre 8.33
> and pcre-ocaml 7.0.2 compiled under MinGW (32-bit) but with some very hacky
> effort required.
>
> Wondering if anyone else has succeeded doing this and whether there are any
> GNU autotools experts here who might be able to provide pointers to the
> weird problem with libtool before I brave posting to the autotools list! :o)
>
> (Background: Windows Vista VM running Cygwin 1.7.20, GCC 4.5.3)
> Configured PCRE with:
> ./configure --prefix="C:/Dev/OCaml" --includedir="C:/Dev/OCaml/lib"
> --disable-cpp --enable-utf8 --host=i686-w64-mingw32 --build=mingw32
>
> At this point, make all will freeze (completely crashes the terminal) when
> it gets to libpcre.la. The same goes for PCRE 8.13, 8.20 and 8.21. A limited
> comparison of the sources suggests that the issue is with libtool. The
> workaround I've used is to configure PCRE 8.12 with the same switches and
> then overwrite the libtool script in PCRE 8.33 with the one generated by
> PCRE 8.12's configure. PCRE 8.12 is built with autoconf 2.65 where 8.33 is
> built with autoconf 2.68 (I tried installing autoconf 2.65 and regenerating
> the configure script in 8.33 but that didn't work either).
>
> Having built PCRE 8.33 and installed it, it's necessary to produce a wrapper
> .cmd file for pcre-config so that ocaml setup.ml -build works for pcre-ocaml
> 7.0.2 as unfortunately it's now using ocamlbuild rather than make (which
> could use pcre-config directly).
>
> With both of those shims in place, it does seem to be working - but has
> anyone else been trying or experienced trouble building PCRE on Windows
> since version 8.12? I haven't got the first clue how to debug libtool...
>
>
> David
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs



-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com

RE: [Caml-list] Building pcre-ocaml 7.0.2 on MinGW

[David Allsopp]

Markus Mottl wrote:
> I have no experience with OCaml installations on Windows, but what
> concerns the configuration of pcre-ocaml, it actually does use pcre-
> config.  If the latter is not in your path, you can add the configure flag
> "--with-pcre-config {full path to pcre-config}" to make it work.

The problem is more subtle than that - pcre-config is there but it's a shell script which means that make (which uses sh) can execute it but ocamlbuild (which uses cmd on a Windows build) cannot. Arguably it's a deficiency of the Windows build of PCRE that it doesn't generate a .cmd version of pcre-config (but that's another m4 related headache!). I made the following two changes for my build environment:

After running ./configure (but therefore before make install) for PCRE:
	sed -i -e "1s/$/\n\nPATH=\/bin:\$PATH/" pcre-config
(that's necessary because when bash is invoked from a command shell it will interpret the Windows PATH and you need access to uname and test from Cygwin's /bin)

And then after installing I created pcre-config.cmd in the same directory as pcre-config (and therefore in my PATH as that's my OCaml bin directory):
@setlocal
@echo off
bash /cygdrive/c/Dev/OCaml/bin/pcre-config %*

It's possible that ocamlbuild could workaround this without the need for the extra script, but it's probably better to fix PCRE itself...


David 

Re: [Caml-list] Building pcre-ocaml 7.0.2 on MinGW

[Adrien Nader]

Hi,

I haven't tried anything with pcre but generally-speaking, these
foo-config need to die in favor of pkg-config.
My linux installation has around 70 of them and they all duplicate the
same functionality, usually badly.

Hopefully, there is pkg-config support for pcre and the best thing to do
is probably to change the bindings to use pkg-config instead of
pcre-config. The arguments are the same so it should be fairly painless
(you only have to call "pkg-config libpcre" instead of "pcre-config").

Hope this helps,
Adrien Nader

Re: [Caml-list] Building pcre-ocaml 7.0.2 on MinGW

[Markus Mottl]

It would certainly be easy to switch to pkg-config.  I just don't know
which tool is considered the most portable choice for pcre.  I haven't
heard from others yet that they had problems with pcre-config so I'm
not sure switching will improve things.  FWIW, both pcre-config and
pkg-config seem to be working fine on Mac OS X and on CentOS.

Regards,
Markus

On Wed, Jun 19, 2013 at 12:32 PM, Adrien Nader <adrien@notk.org> wrote:
> Hi,
>
> I haven't tried anything with pcre but generally-speaking, these
> foo-config need to die in favor of pkg-config.
> My linux installation has around 70 of them and they all duplicate the
> same functionality, usually badly.
>
> Hopefully, there is pkg-config support for pcre and the best thing to do
> is probably to change the bindings to use pkg-config instead of
> pcre-config. The arguments are the same so it should be fairly painless
> (you only have to call "pkg-config libpcre" instead of "pcre-config").
>
> Hope this helps,
> Adrien Nader



-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com