Closed devosgit closed 3 years ago
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
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
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 =
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?
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?
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
What is the test checking for? What does "$have_ar" mean? Is something missing from my system?
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
@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.
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
. 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.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.
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 ?
CppAD 20180000 is now available; see https://www.coin-or.org/download/source/CppAD/
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.
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
I was finally able to get the build to complete. These are the steps I took:
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!
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!
@tkralphs, I emailed you at ted@lehigh.edu. Is this still a good email address for you?
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:
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). 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.
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.
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.
I think this issue has been fixed ? If so, would you please close it.
I'm checking it. Was there a specific fix? I didn't find one.
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
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.
Is this still an open problem ?
Yes, I believe it is still a problem.
On Thu, Oct 15, 2020, 9:33 AM Brad Bell notifications@github.com wrote:
Is this still an open problem ?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/coin-or/CppAD/issues/25#issuecomment-709367270, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC5GAYQBUOC7XYI3DLDNUWDSK4B4LANCNFSM4EKSHDCA .
Can you capture the command used to execute the CppAD configure
; i.e., what options are in the command.
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.
It would help me if you could specify a script for me to run that would generate the problem.
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 notifications@github.com 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 https://github.com/coin-or/CppAD/issues/25#issuecomment-709432147, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC5GAYRWQU3NK2DNHYNHAWDSK4NOLANCNFSM4EKSHDCA .
@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.
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).
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
Ok, I will wait for the shiny new version with the issue corrected. 😀
Thanks!
On Thu, Oct 15, 2020, 12:20 PM Ted Ralphs notifications@github.com 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 https://github.com/coin-or/CppAD/issues/25#issuecomment-356020287, 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 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.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/coin-or/CppAD/issues/25#issuecomment-709472280, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC5GAYX7JPEEQRF7V5VDWLLSK4VPLANCNFSM4EKSHDCA .
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 ?
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.
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.
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
I was using gcc in the build above. I need to get 'cl' and ifort in my path.
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.
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.
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
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.
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 ?
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 https://github.com/coin-or/CppAD/commit/809284aef03302c0f2c4628581e503841205e11f 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).
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.
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 ?
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
https://github.com/coin-or/CppAD/commit/8a818c5ce52afcf2075b4f36cf6027c8c224b0d8
Please try this new version.
Do you know how to launch in the Visual Studio debugger an executable generated by the make test
command ?
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.
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.
It looks to me like you are right and `AM_PROG_ARis not the same as
AM_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).
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
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
I am attempting to build COIN-OS from the latest trunk version. During the make step, the following error results: Making all in cppad make[1]: Entering directory
/c/coin-os/5287.1/cppad' cp cppad/configure.hpp ../../cppad/cppad/configure.hpp SPEED_DIRS = make[1]: SPEED_DIRS: Command not found make[1]: *** [../../cppad/cppad/configure.hpp] Error 127 make[1]: Leaving directory
/c/coin-os/5287.1/cppad' make: *** [all-recursive] Error 1Do you have any idea what would cause this error and what the fix would be? (make.log and config.log for cppad are attached.) make 1-4-18 141pm.log config-cppad.log