Can you run "autoconf --version" on the command line?

/Erik


On 2018-01-03 16:33, Nir Lisker wrote:
Hello Erik,

I installed autoconf 2.69-3 through cygwin (indeed it was listed as 2.5). However, running "bash autogen.sh" still gives:

You need autoconf installed to be able to regenerate the configure script
Error: Cannot find autoconf

If I run "bash configure" I get

Configure source code has been updated, checking time stamps
Running generated-configure.sh

And that's it. I checked generated-configure.sh and it contains only comments and no script.

In autogen.sh I tried adding a print to help with debugging:

AUTOCONF="`which autoconf 2> /dev/null | grep -v '^no autoconf in'`"
echo "AUTOCONF is ${AUTOCONF}"

which prints

AUTOCONF is

Apologies for the mess. How do I continue?

- Nir

On Wed, Jan 3, 2018 at 4:54 PM, Erik Joelsson <erik.joels...@oracle.com <mailto:erik.joels...@oracle.com>> wrote:

    Hello Nir,

    On 2018-01-03 15:34, Nir Lisker wrote:
    Thanks for the detailed reply.

    Iv'e changed the logic in toolchain_windows.m4 and got this message:

    Configure source code has been updated, checking time stamps
    Warning: The configure source files is newer than the generated
    files.
    Cannot locate autoconf, unable to correct situation.
    Please install autoconf and run 'bash autogen.sh' to update the
    generated files.
    Error: Cannot continue

    I downloaded autoconf 2.69. How do I point to it? There is no
    installation.

    If you downloaded the src distro, then you need to compile and
    install it with something like

    $ ./configure
    $ make
    $ make install

    On Windows it's probably easier to just get it through cygwin.
    Note that the cygwin installer probably still lists autoconf as an
    old version in the name, but last I checked it was 2.69 that they
    actually provided. On Linux, just use your favorite package
    installation tool (apt, yum etc).

    As long as it's on the path, autogen.sh will pick it up. Configure
    will also detect that you changed an .m4 file and run autogen.sh
    for you automatically, which is what happened to you above.

    /Erik

    On Wed, Jan 3, 2018 at 3:24 PM, Erik Joelsson
    <erik.joels...@oracle.com <mailto:erik.joels...@oracle.com>> wrote:

        Hello Nir,

        On 2018-01-03 13:05, Nir Lisker wrote:

            When trying to build JDK 11 on Windows 10 with VS Express
            2013 Update 4 (as
            stated in the docs - the highest supported version) the
            build fails:

        AFAIK, this should work, though I have only ever used VS 2013
        Professional.

            bash configureĀ  --with-tools-dir='C:\Program Files
            (x86)\Microsoft Visual
            Studio 12.0\VC\bin'

        If VS is properly installed in the default location, there
        should be no need to specify --with-tools-dir. Configure will
        look in the default location automatically.

            ...
            configure: Found Visual Studio installation at
            /cygdrive/c/Program Files
            (x86)/Microsoft Visual Studio 12.0/ using --with-tools-dir
            configure: Warning: vc/bin/amd64/vcvars64.bat is missing,
            this is probably
            Visual Studio Express. Ignoring
            configure: Found Visual Studio installation at
            /cygdrive/c/Program Files
            (x86)/ using --with-tools-dir
            configure: Warning: vc/bin/amd64/vcvars64.bat is missing,
            this is probably
            Visual Studio Express. Ignoring
            configure: The path given by --with-tools-dir does not
            contain a valid
            configure: Visual Studio installation. Please point to
            the VC/bin or
            VC/bin/amd64
            configure: directory within the Visual Studio installation
            configure: error: Cannot locate a valid Visual Studio
            installation
            configure exiting with result code 1

            /Microsoft Visual Studio 12.0/VC/bin/ does not contain an
            /amd64 folder,
            instead it has /x86_amd64. Also, vcvars64.bat is located
            directly under
            /VC/bin.

        This is strange. Looking at the configure source, we assume
        that the VS installation should contain
        "vc/bin/amd64/vcvars64.bat". If that file isn't found,
        configure doesn't recognize the VS installation.
        Unfortunately I don't have an Express installation to look
        at, but my old professional installation has that file. In
        VC/bin I only have vcvars32.bat.

        I'm pretty sure this layout was how the express edition used
        to look as well. Otherwise Magnus wouldn't have written the
        build doc claiming it would work.

        This means the file layout for Visual Studio 2013 has
        changed, or that it's different on Windows 10 (our builds are
        on older versions of Windows still).

        If you would like to try to fix this, the logic that needs
        updating is in make/autoconf/toolchain_windows.m4, in the
        macro TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT.

            Iv'e made another attempt using /Microsoft Visual Studio
            11.0/VC/bin/ which
            resulted in the same error. This folder also has
            vcvars64.bat directly
            under it. It also contains an /amd64 folder with a couple
            of dlls inside.

            Since I'm specifying the path to the /VC/bin dir I don't
            understand why
            it's still complaining. What am I doing wrong?

        Because of how different the versions of Visual Studio are,
        configure will not automatically assume or try a different
        version than the default without being told to. If you want
        to try 2012, you need to tell configure using
        --with-toolchain-version=2012. No need to specify tools dir
        as long as it's installed in the default location.

            On a related note, is it possible to update the build
            requirements to work
            with VS 2017? OpenJFX already uses this version.

        This will likely happen in JDK 11 time frame. Note though
        that changing compilers is usually a pretty big effort so it
        will take a while.

        /Erik

            - Nir






Reply via email to