SPEED_DIRS: Command not found when compiling under MSYS/MS cl about cppad

[bradbell]

I am not sure what the problem is here. Would you please search for
SPEED_DIRS *=
in the top level make file and report the corresponding text. The corresponding text in my version is
SPEED_DIRS = \
speed/src \
$(SPEED_TESTS)
and
# SPEED_DIRS =

The autotools method for configuring CppAD was deprecated on 2012-12-26; see
https://www.coin-or.org/CppAD/Doc/autotools.htm

You would get a much better configuration of CppAD using cmake
https://www.coin-or.org/CppAD/Doc/cmake.htm

[devosgit]

SPEED_DIRS does not appear in the top level Makefile at all.

The makefile in the cppad subdirectory has these lines:
$(top_srcdir)/cppad/configure.hpp: cppad/configure.hpp
cp cppad/configure.hpp $(top_srcdir)/cppad/configure.hpp
SPEED_DIRS =

[devosgit]

The makefile in the cppad subdirectory also has these lines:

IPOPT_HEADER = 
#
#IPOPT_HEADER = \
#	cppad_ipopt/src/cppad_ipopt_nlp.hpp

#
# Is the library archiving program present
#SPEED_TESTS = \
#	$(SPEED_ADOLC_TESTS)  \
#	speed/cppad \
#	speed/double \
#	speed/example \
#	$(SPEED_FADBAD_TESTS) \
#	speed/profile \
#	$(SPEED_SACADO_TESTS)

#
#SPEED_DIRS = \
#	speed/src \
#	$(SPEED_TESTS)

Maybe these lines were commented out because Ipopt was skipped in the configuration step.

If I build CppAD using cmake prior to running configure, how would I prevent configure from writing over the CppAD make files?

[devosgit]

I found these lines in cppad\makefile.am.

# Is the library archiving program present
if CppAD_HAVE_AR
SPEED_TESTS = \
	$(SPEED_ADOLC_TESTS)  \
	speed/cppad \
	speed/double \
	speed/example \
	$(SPEED_FADBAD_TESTS) \
	speed/profile \
	$(SPEED_SACADO_TESTS)
#
SPEED_DIRS = \
	speed/src \
	$(SPEED_TESTS)
else
	SPEED_DIRS =
endif

My problem may be that CppAD_HAVE_AR is not set. Where/how do I set that?

[bradbell]

As I mentioned, it is better to use cmake to configure and test CppAD. I you want to keep using the autotools, see line 478 in
https://github.com/coin-or/CppAD/blob/master/configure.ac

where the following text appears:
dnl check if we can build libraries
AM_CONDITIONAL(CppAD_HAVE_AR, test "$have_ar" = 'yes' )
if test "$have_ar" = 'no'; then
AC_MSG_WARN(
[cannot build any libraries because ar is missing; e.g,, speed/* not built]
)
fi

[devosgit]

What is the test checking for? What does "$have_ar" mean? Is something missing from my system?

[bradbell]

Testing is to make sure that the CppAD works properly on your system. If you insist on using the autotools, instead of cmake, see the file bin/autotools.sh
https://github.com/coin-or/CppAD/blob/master/bin/autotools.sh
which I use for autotools configuration and testing.

have_ar should be yes if your system has the ar program. You can use the command
which ar
to determine if you system has the ar command.Here is what I get after running configure on my system.
build>grep have_ar config.log
configure:4151: have_ar = yes

[tkralphs]

@bradbell As you know, we are still using the autotools for building of the various COIN projects. Unless someone volunteers to port the entire build system to CMake, we'll have to continue on that path for the foreseeable future. I don't think @DevOs is insisting on using the autotools, it is the only option we're offering to build OS.

With that said, there are multiple things going on here.

1. The version of CppAD being used in OS trunk at the moment is 20150000 if one checks the code out with SVN, since that is what's listed in svn:externals. The Dependencies file, on the other hand, lists version 20170000 so with a git clone, building with the get.depedencies script, you get a different version. There seems to be a genuine bug in 2015000 that was fixed by 2017000.
2. However, in the latest version of CppAD, there are other issues. You seem to have hard-wired the requirement to have the ar command available, since configure.ac in master contains the command have_ar = yes rather than the actual check for the existence of ar (see here). So CppAD_HAVE_AR is now always true, whether the ar command is available or not.
3. There is actually an ar command available in MSys2, but it is in the \mingw64\bin directory, which is most likely not in @devosgit's path, so that is the ostensible reason for the failure in this case. However, adding the ar command to the path doesn't fix the problem. The ar command is not the right command to use when building with cl. The command that should be used is the lib command. This is the reason for the patches applied to libtool which are applied in the COIN_PATCH_LIBTOOL_CYGWIN in coin.m4 here. It's possible ar could be made to work for what you are trying to do, but if nothing else, you are assuming a .o extension for the object files and it's .obj for cl.

With all that said, the easiest fix is to re-instate the check for the ar command and not to build speed/* as I guess was done previously. Even this is not a complete fix, since the build will fail in MSys with the cl compiler if the user actually does have the ar command in the path for reasons pointed out earlier.

Alternatively, an immediate fix for @devosgit is to revert to version 2013000 (possibly some later version would work, but this is the one I've been using in the optimization suite and that still builds). This can be done with

svn switch https://projects.coin-or.org/svn/CppAD/stable/20130000

in the cppad directory of the checkout of the OS trunk.

[bradbell]

1. I am not suggesting converting all of coin to use cmake, just the install of CppAD. You must have other tools used by coin that require cmake, so this would not add any extra requirements ?

2. CppAD 20180000 is now available; see
   https://www.coin-or.org/download/source/CppAD/

3. Thanks for pointing out that I had assumed ar is available for the autotools install. I have tried to avoid extending the autotools install, and instead have put most of the work into the cmake install. If you have a patch for configure.ac, I will be glad to make the change.

[tkralphs]

Unfortunately, CppAD is the only tool used by COIN-OR that requires CMake, so this would add extra requirements. I just don't have the bandwidth to look into what would be involved in using CMake for just this one project.

I assume that adding back in what was in configure.ac in 2013000 would at least fix the issue of what do do when ar is not present.

AC_CHECK_PROG(have_ar, [ar], [yes], [no])
AM_CONDITIONAL(CppAD_HAVE_AR, test "$have_ar" = "yes")

Something like

    case $build in
      *-cygwin* | *-mingw*)
        case "$CC" in
          cl* | */cl* | CL* | */CL* | icl* | */icl* | ICL* | */ICL*)
            have_ar=no
            ;;
        esac
     esac

Would suppress the use of AR with the cl compiler. I can try this a bit later and let you know.

Better yet would be to use lib instead of ar when cl is used. I guess you're using the stock libtool, which needs a patch to work properly with cl. If you patch libtool as we do in coin.m4, then this will take care of it. I guess you might be able to copy and past the m4 function that does the patching into your own autoconf files, since you don't use the standard build harness or perhaps

[devosgit]

I was finally able to get the build to complete. These are the steps I took:

• I had to uninstall the smaller MSYS installation and install MinGW (www.mingw.org) to get the ar program. I installed only mingw32-base, msys-base, msys-patch, msys-unzip. I also installed msys-perl and msys-m4 because I needed to build autotools to fix another issue.
• Because the OS 2.10 User's Manual states that the gcc compiler included in MinGW can interact negatively with the Microsoft cl compiler, I removed gcc from the MinGW installation. These components of 'The GNU C Compiler' were removed: mingw32-gcc bin, mingw32-gcc dev, mingw32-gcc lic. 'The GNU C Compiler Shared Runtime Library' (mingw32-libgcc dll) must be kept because dos2unix depends on it.
• I added the configuration option --enable-msvc to force use of the cl compiler.
• I added LDFLAGS=-no-undefined to the make command to pass this option to libtool to enable it to link shared DLLs.

Configure and make completed with no errors and the unit tests passed, so everything looks good so far. I have not started using the API yet in any applications, but I hope all the components will play nicely together.

Thank you both for all your help!

[tkralphs]

I'm not sure if you're using Msys2, but if not, you should. It has a real package manager, which simplifies a lot of stuff. Once you install the base, installing something like MinGW is just a matter of running a command like

pacman -S mingw-w64-x86_64-toolchain

I think the advice about the MinGW compiler interacting negatively with cl is baseless. I've built OS many times with both gcc and cl installed with no problems. It's strange that the ar command is needed for the compilation to go through with 2013000, but it does seem to be. Anyway, glad you got it going!

[devosgit]

@tkralphs, I emailed you at [email protected]. Is this still a good email address for you?

[tkralphs]

I'm just getting back to trying to build the Optimization Suite with cl under Msys2. The issue reported here is still present and still causes the build to fail. It looks like there are two things that need to be fixed:

1. You are still hard-coding the presence of ar (see above). I think deleting the line have_ar='yes' from configure.ac will allow the build to go through, but I'm not exactly clear on what you're doing in your configure.ac. It seems like a better fix would be to define AR to be lib in the case of cl (lib is the archive program used by Visual Studio).
2. After this, there seems to be an error in makefile.am. When ar is not present, you have

	SPEED_TESTS =
	SPEED_DIRS =

but this should probably be

	SPEED_TESTS = ""
	SPEED_DIRS = ""

With the former, SPEED_TESTS is interpreted as a command rather than assigned the value of an empty string, which is what you intend. This was the source of the error reported originally.

I made these two change by hand in configure and makefile and the build went through.

[bradbell]

The reason I hard code ar I no longer support changes to the auto-tools install of CppAD. There was some complicated autotools logic that I did not want to support, so I just replaced it by have_ar='yes' and restricted the autotools build to that case. I figured that eventually, people would swtch over to installing CppAD using cmake.

If you send me a pull requrest with changes to the autobuild files, I make then.

[tkralphs]

I cannot easily send you a pull request, as we discussed last time, because you are using a different version of the autotools than the rest of COIN-OR. If you add an appveyor.yml to do testing on Windows and adding running the autotools with the version you prefer as part of your automatic build and test setup, then I could try submitting a PR and see if it builds properly on appveyor.

Alternatively, if you switch to the COIN standard autotools setup (once we move to a more modern version), I can easily test and fix things and submit PRs. I would be happy do to this and maintain all of this for you. That is the advantage of using the standard setup.

This particular thing looks to be an easy fix. I suggested a fix above, but you seem to be using a different macro for detecting ar than what I suggest. That macro seems to be working so just simply not hard-coding have_ar (delete one line from configure.ac and adding four quotation marks to Makefile.am should hopefully fix it.

[bradbell]

I think this issue has been fixed ?
If so, would you please close it.

[tkralphs]

I'm checking it. Was there a specific fix? I didn't find one.

[bradbell]

I think the fix is checking for the AR program in configure.ac, but I am not sure; see

# check if we have ar program
have_ar='yes'
AM_PROG_AR([have_ar='no'])
AC_MSG_NOTICE([have_ar = $have_ar])

in configure.ac

[tkralphs]

This seems to still be broken. I now get

/home/tkral/coinbrew/cppad/ar-lib lib cru libspeed.a link_det_lu.obj link_det_minor.obj link_mat_mul.obj link_ode.obj link_poly.obj link_sparse_hessian.obj link_sparse_jacobian.obj microsoft_timer.obj
make[1]: /home/tkral/coinbrew/cppad/ar-lib: Command not found
make[1]: *** [makefile:411: libspeed.a] Error 127
make[1]: Leaving directory '/home/tkral/coinbrew/build-msvc2017-md-3/cppad/20190200/speed/src'
make: *** [makefile:627: all-recursive] Error 1

I haven't dug into it yet to see what's going on now.

[bradbell]

Is this still an open problem ?

[devosgit]

Yes, I believe it is still a problem.

…

On Thu, Oct 15, 2020, 9:33 AM Brad Bell ***@***.***> wrote: Is this still an open problem ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC5GAYQBUOC7XYI3DLDNUWDSK4B4LANCNFSM4EKSHDCA> .

[bradbell]

Can you capture the command used to execute the CppAD configure; i.e., what options are in the command.

[tkralphs]

I spent a lot of time digging into this when it was first reported and identified the problem as well as possible solutions. The information is all captured in the conversation above, but no solutions have yet been implemented. I'm not sure what else you need to move forward.

One thing that was mentioned which has now happened is that there is a new version of the COIN-OR BuildTools that is based on a current version of the autotools. I could try to help in putting together a new set-up based on that standard harness that I would then be able to more easily help maintain going forward.

[bradbell]

It would help me if you could specify a script for me to run that would generate the problem.

[devosgit]

It has been a couple of years since I was trying to get this working. As soon as I have a chance, I will look through my files and try to find a script that generates the problem. I think I may have found a fix that I hacked in my installation. My memory fails me at the moment. 😊 Thanks,

…

On Thu, Oct 15, 2020, 11:12 AM Brad Bell ***@***.***> wrote: It would help me if you could specify a script for me to run that would generate the problem. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC5GAYRWQU3NK2DNHYNHAWDSK4NOLANCNFSM4EKSHDCA> .

[tkralphs]

@devosgit Things have changed quite a bit in terms of how to fetch and build projects since this issue was opened, so it probably isn't worth your time to go digging. You did report how you fixed the issue here, but it's not really a sustainable solution. @bradbell I am replicating the build now, but for you to do the same, you would need to build in MSys2 with cl and ifort. If you're up for that, I can easily tell you how to do it, but it does depend a little on your setup. If you can tell me whether you already have MSys2 installed and have experience with it, that would be helpful. Aside from that, it is a straightforward build using coinbrew.

coinbrew fetch OS@master
coinbrew build OS --enable-msvc --build=x86_64-w64-mingw32

Once you are in MSys2 bash with cl and ifort available, that's it.

[bradbell]

I now have a virtaul windows machine and have fixed some issues with Visual Studio and the tests.
I will try and get minsys2 up and running so yes (I am up for it).

[tkralphs]

OK, just verified that it's still broken in your latest release 20200000.3. To set up coinbrew in Msys2, follow the directions here and let me know if you have any problems. I guess you don't need to actually build the entire OS stack to see the issue. I guess if you just make sure cl and ifort are in your path and do the usual configure; make; make install, you should see the error. I eventually get this:

make[1]: /home/tkral/Projects/cppad/ar-lib: No such file or directory
make[1]: *** [makefile:410: libspeed.a] Error 127
make[1]: Leaving directory '/home/tkral/Projects/build-msvc2017/cppad/20150000/speed/src'
make: *** [makefile:626: all-recursive] Error 1

but it's clear that this is caused by the fact that you are forcing have_ar to be yes.

checking for ar... no
checking for lib... lib
checking the archiver (lib) interface... lib
configure: have_ar = yes

[devosgit]

Ok, I will wait for the shiny new version with the issue corrected. 😀 Thanks!

…

On Thu, Oct 15, 2020, 12:20 PM Ted Ralphs ***@***.***> wrote: @devosgit <https://github.com/devosgit> Things have changed quite a bit in terms of how to fetch and build projects since this issue was opened, so it probably isn't worth your time to go digging. You did report how you fixed the issue here <#25 (comment)>, but it's not really a sustainable solution. @bradbell <https://github.com/bradbell> I am replicating the build now, but for you to do the same, you would need to build in MSys2 with cl and ifort. If you're up for that, I can easily tell you how to do it, but it does depend a little on your setup. If you can tell me whether you already have MSys2 installed and have experience with it, that would be helpful. Aside from that, it is a straightforward build using coinbrew. coinbrew fetch ***@***.*** coinbrew build OS --enable-msvc --build=x86_64-w64-mingw32 Once you are in MSys2 bash with cl and ifort available, that's it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC5GAYX7JPEEQRF7V5VDWLLSK4VPLANCNFSM4EKSHDCA> .

[bradbell]

I have a virtual windows machine with msys2 installed and followed the directions in
https://coin-or.github.io/user_introduction.html#setting-up-coinbrew

up to and including cloning the coin-brew repository. I am not sure what I should do next ?

[tkralphs]

Either try to build the entire OS stack until reaching cppad by following the steps here or else don't use coinbrew at all for now and just try to build and install cppad as usual. I just tried myself and if I do

mkdir build
cd build
../configure
make

it ends with the error

$ make
Making all in speed/src
make[1]: Entering directory '/home/tkral/Projects/cppad/build/speed/src'
source='../../../speed/src/link_det_lu.cpp' object='link_det_lu.obj' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../../depcomp \
g++       -I../../../include    -c -o link_det_lu.obj `cygpath -w '../../../speed/src/link_det_lu.cpp'`
../../../depcomp: line 772: exec: g++: not found
make[1]: *** [makefile:446: link_det_lu.obj] Error 127
make[1]: Leaving directory '/home/tkral/Projects/cppad/build/speed/src'
make: *** [makefile:626: all-recursive] Error 1

In this case, although configure does detect the presence of cl and appears to set it as the default compiler, it still falls back to g++ somewhere. If I do

mkdir build2
cd build2
../configure --enable-msvc
make

then I get the error previously reported.

[bradbell]

I have a different bug that came up with the test. I am working on it and will get back to your once it is out of the way.

[bradbell]

I fixed some problems and my msys2 system now builds and runs the tests successfully with:

git clone https://github.com/coin-or/CppAD.git cppad.git
cd cppad.git
mkdir build
cd build
../configure
make test

see the heading 10-17 on
https://coin-or.github.io/CppAD/doc/whats_new_20.htm

[bradbell]

I was using gcc in the build above. I need to get 'cl' and ifort in my path.

[bradbell]

I am trying to figure out how to set the paths for Visual Studio 2019 in a msys window but the directories seem to have a much different structure than step 4 in
https://www.coin-or.org/OS/documentation/node16.html

By the way, what does node16 refer to ? Can it change each time you build the documentation. If so this is a problem with the documentation tool.

[tkralphs]

I doubt that the OS documentation is up-to-date, so I wouldn't look at that. The documentation pointed you to is the most up-to-date for building OS and the issue of setting paths correctly is addressed here:

https://coin-or.github.io/user_introduction.html#building-with-visual-studio-in-msys2

The OS documentation looks like it was generated with latex2html, which used to be one of the most popular tools for generating HTML documentation before Markdown took over. That is just how it works. It produces an HTML translation of a Latex document, so a "node" is kind of like a "page" in a PDF. Neither should really be directly referenced. There are much better tools now, obviously, but this documentation was written a long time back. I also have some old documentation made this way that I want to upgrade.

[bradbell]

It appears the name of vcvarsall.bat has changed; see
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/how-to-set-environment-variables-for-the-visual-studio-command-line
I executed the VsDevCmd.bat as specified above.

I also executed the path command
set PATH=C:\msys64\usr\bin;%PATH%

I un-installed gcc and its dependencies with
pacman -Rs gcc

I then ran

mkdir build
cd build
../configure | tee configure.out

The output of the configure command contained the following lines

checking for g++... no
checking for cl.exe... cl.exe
checking whether we are using the GNU C compiler... no
checking for ar... no

When I enter make I get the error message saying

Making all in speed/src
make[1]: Entering directory '/home/bradl/cppad.git/build/speed/src'
source='../../../speed/src/link_det_lu.cpp' object='link_det_lu.obj' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../../../depcomp \
g++       -I../../../include    -c -o link_det_lu.obj `cygpath -w '../../../speed/src/link_det_lu.cpp'`
../../../depcomp: line 772: exec: g++: not found
make[1]: *** [makefile:446: link_det_lu.obj] Error 127
make[1]: Leaving directory '/home/bradl/cppad.git/build/speed/src'
make: *** [makefile:625: all-recursive] Error 1

[tkralphs]

I still have vcvarsall.bat in Visual Studio 17 and Visual Studio 19 has at least vcvars64.bat, but the location has changed from where it used to be. I don't have a local copy to check Visual Studio 2019, but we are still using those batch scripts in our Appveyor testing on Windows and they work fine. See here.

Anyway, yes, that's the exact error I reported above. If you add the argument --enable-msvc, you get a different error. Both indicate issues.

[bradbell]

It seems to me that configure is confused if it says g++ is not available and then the make command trys to use it ? Looks like a bug in the autotools ?

OK, with --enable-msvc I get:

aking all in speed/src
make[1]: Entering directory '/home/bradl/cppad.git/build/speed/src'
rm -f libspeed.a
/home/bradl/cppad.git/ar-lib lib cru libspeed.a link_det_lu.obj link_det_minor.obj link_mat_mul.obj link_ode.obj link_poly.obj link_sparse_hessian.obj link_sparse_jacobian.obj microsoft_timer.obj
make[1]: /home/bradl/cppad.git/ar-lib: No such file or directory
make[1]: *** [makefile:410: libspeed.a] Error 127
make[1]: Leaving directory '/home/bradl/cppad.git/build/speed/src'
make: *** [makefile:625: all-recursive] Error 1

I see, the problem is /ar-lib: No such file or directory. It is strange that AM_PROG_AR is finding the archiver, but it is not using it correctly ?

[bradbell]

I am kind of stuck here. I do not know why AM_PROG_AR is finding an archiver but not using it correctly.

There was a problem using bin/autotools.sh (to re-run the autotools) that I just fixed; see
809284a
This may help you try different things.

P.S.
If I change configure.ac so that have_ar is no, a lot of the tests build but I get a CppAD memory leak check error (that may be due to mixing debug and release code).

[tkralphs]

I do not know why AM_PROG_AR is finding an archiver but not using it correctly.

I don't believe the archiver is being found, it only thinks it is being found because you are over-riding the check by setting have_ar to yes, which it seems to me you definitely should not do. So the first step would be not to do that. Then we can figure out how to fix other issues that arise subsequently. I won't be able to look at this until later today, but then I can try to help.

[bradbell]

It appears that having an argument in AM_PROG_AR is messing up the archiver check.

Here is what I have tried and you should be able to reproduce:

git reset --hard
git pull

Then edit configure.ac changing the line
AM_PROG_AR([have_ar='no'])
to the line
AM_PROG_AR()
This should force an error exit during configure if the archiver is not found; see
https://www.gnu.org/software/automake/manual/html_node/Public-Macros.html

Next run the following commands:

bin/autotools.sh automake
rm -rf build
mkdir build
cd build
../configure --enable-msvc

In the configure output you will see
checking the archiver (lib) interface... lib
This is the output form the AM_PROG_AR program which says to me that the archiver has been found. Then enter
make test
Many of the tests will pass, but eventually I CppAD detects
memory_leak Error
I need to track this down but I think it is a separate issue.

I think what I should do is to remove the have_ar variable and conditions from the autotools build
and just let AM_PROG_AR fail in that case ?

[bradbell]

I removed have_ar from the configuration and called AM_PROG_AR() ; i.e., with not arguments so it should abort configuration with an error message if it fails; see
8a818c5

Please try this new version.

[bradbell]

Do you know how to launch in the Visual Studio debugger an executable generated by the make test command ?

[tkralphs]

The new version gets the same errors, which I guess it must for you, too, right? The first error, where you are using g++ even though it's not present is still arising. If I add --enable-msvc, then it does now find the Visual Studio lib program as the archiver, but invoking that requires a wrapper called ar-lib, which is supposed to exist in your repository. That is the error about ar-lib missing. For example, here is the copy that lives in the Cbc repo: https://github.com/coin-or/Cbc/blob/master/ar-lib. If I add that to the root of your checkout, it gets further, but then there is just some standard compiler error. You have some code somewhere that's incompatible with the Visual Studio compiler.

You should really look at what we're doing in our m4 scripts for all of this (and again, I would think the easiest path would be to just utilize our build infrastructure, which already has all this stuff worked out). We are using libtool, which also makes a lot of things easier. Check here for the stuff related to the archiver.

https://github.com/coin-or-tools/BuildTools/blob/master/coin.m4#L335

One thing to note is that AC_PROG_AR() may not be the same as AC_PROG_AR. By calling it with (), I think you may be actually saying "don't no anything on fail" rather than what you want, which is for the whole configuration to fail on failure of that test.

[tkralphs]

Do you know how to launch in the Visual Studio debugger an executable generated by the make test command ?

It's been a very long time since I tried this. You would obviously need to build with debugging symbols enabled and then I think I recall there is a way of adding an already built to a project so that you can debug it. Poke around the menus and just look for some option to add things to the project. There must be documentation on doing this somewhere.

[bradbell]

It looks to me like you are right and `AM_PROG_ARis not the same asAM_PROG_AR()``.
I have changed to the form without the ``()`` and now get ``make test`` to work up to the following error (please try it):

... snip ...
vec_ad              OK
check_for_nan       OK
memory_leak         Error
1 tests failed.
End test group example/general

Debugging the memory leak error will not be easy without a debugger. (When I use cmake to create visual studio files I do not get this error).

[bradbell]

I figured out the memory leak. We need to configure with

../configure --enable-msvc CXX_FLAGS='-EHsc'

Without it we get the warning:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\ostream(448): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc

see
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4530?view=vs-2019

[bradbell]

I am still getting the warning:

cl : Command line warning D9035 : option 'o' has been deprecated and will be removed in a future release

It seems that, for the Microsoft cl compiler, the autotools need to change the -o flag; see
https://docs.microsoft.com/en-us/cpp/build/reference/output-file-f-options?view=vs-2019

[tkralphs]

Yes, that warning always pops up and has for many years with cl. I think if you use the latest libtool, it may take care of it, but it can be safely ignored.

You still haven't added ar-lib to your repo, so from a clean checkout, the same errors arise. You also didn't fix the error that arises when not adding --enable-msvc (things should still work in this case). But if I add ar-lib manually and also use the argument --enable-msvc, then things look OK until I hit the compiler error

C:\msys64\home\tkral\Projects\cppad\cppad_lib\json_lexer.cpp(224): error C2039: 'isdigit': is not a member of 'std'

This is a known problem with older versions of cl (I believe I'm using Visual Studio 2015 for my testing). If you want to remain compatible with some older (but not that old) versions of cl, which I would recommend, you should fix those issues.

[bradbell]

If you go to
https://www.gnu.org/software/automake/manual/automake.html#Auxiliary-Programs
There is a reference to ar-lib and above it says
`all of these files are distributed and installed with Automake'

So I should be able to get this file through pacman ?

[tkralphs]

I don't think so. There are a number of auxiliary programs that are distributed as part of the autotools and that need to be included in the source distribution of any software that uses the autotools, but since those programs are not generally invoked directly by users, they would not be installable using a package manager. That is why I pointed out where ar-lib is included in Cbc, as an example. There are others as well, like config.sub, config.guess, install-sh that play a similar role, but you already added those at some point. You probably just forgot. Anyway, you can just copy ar-lib from Cbc if you want. How are you getting so far without it, though?

[bradbell]

I will try putting ar-lib in the top source directory.

It seems to me that ar-lib is similar to config.sub and the autotools distribute config.sub with the package but not ar-lib ?

[bradbell]

I now see what is going on. I have a local copy of config.sub in the repository, but ar-lib is a link:

cppad.git>ls -l ar-lib
lrwxrwxrwx. 1 bradbell bradbell 31 Sep 29 06:22 ar-lib -> /usr/share/automake-1.16/ar-lib

cppad.git>ls -l config.sub
-rwxr-xr-x. 1 bradbell bradbell 31428 Oct 21 17:25 config.sub

cppad.git>ls -l /usr/share/automake-1.16/config.sub
-rwxr-xr-x. 1 root root 31428 Jul 24  2019 /usr/share/automake-1.16/config.sub


``

[bradbell]

I added ar-lib to the top source directory, but it still trys to use g++ when I build without the --enable-msvc flag.

[tkralphs]

In the case without --enable-msvc, configure is still finding cl and is setting that as the C++ compiler, so it's not a problem with configure setting the wrong compiler. There must be a mistake somewhere in your setup that causes the use of g++. I can look for it myself if you are not able to find it, but I guess a little grepping will turn it up. By the way, --enable-msvc is a custom flag, not an autotools flag. It is the flag we use to indicate that the compiler search order should be changed to prioritize the microsoft compiler, but it shouldn't have any effects beyond that.

[bradbell]

I have looked and do not know what is causing it to use g++ when it says it cannot find g++. Any help in this regard would be welcome. In addition, after I execute

../configure --enable-msvc CXX_FLAGS='EHsc'
make test

Many of the tests pass until I get to the error

... snip ...
vec_unary.obj
LINK : fatal error LNK1181: cannot open input file '..\..\cppad_lib.obj'
make[1]: *** [makefile:682: general.exe] Error 2
make[1]: Leaving directory '/home/bradl/repo/cppad.git/build/test_more/general'
make: *** [makefile:909: check-am] Error 2

You can run make test in the build/test_more/general directory and get this message without building and running the other tests. I do not know what automake is expecting in test_more/general/makefile.am so that this library gets found ?

[bradbell]

I had to do some fixing of the cmake build due to this issue:
https://discourse.cmake.org/t/on-windows-check-cxx-source-runs-is-calling-check-source-runs/2065

Install cmake for win64-x64; see
https://cmake.org/download/
make sure you select the box that adds cmake to your execution path.

The following can now be used to build and check cppad on windows:

rm -r build
mkdir build
cd build
cmake -G "NMake Makefiles" -D debug_which="debug_all" ..
nmake check

[bradbell]

It is unfortunate that the version of cmake installed by pacman does not support the NMake Makefiles generator option, it used to support it. I had to changed my install instructions for Visual Studio because of this change to pacman.

I have posted an issue about this at
msys2/MINGW-packages#7175

[bradbell]

As it turns out, Visual Studio 2019 includes a version of cmake that generates NMake Makefiles at
/c/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/bin/cmake

As mentioned in msys2/MINGW-packages#7175 one can also use
pacman -S mingw-w64-x86_64-cmake
to get a version that generates NMake Makefiles.

[tkralphs]

This problems seems to be fixed now in master! It would be great if there could be a release that includes the fixes. There is another separate issue related to generation of the pkgconfig file that I will open another issue or pull request for. Thanks!

[bradbell]

I will create a 20210000 release on the first of next year.

[devosgit]

Wow! That is great news. Awesome effort by the two of you. Thank you!

…

On Wed, Dec 16, 2020, 2:05 PM Brad Bell ***@***.***> wrote: I will create a 20210000 release on the first of next year. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC5GAYUEWCHHIUGT5F2K6GDSVEHJZANCNFSM4EKSHDCA> .