Comments (64)
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
from cppad.
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 =
from cppad.
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?
from cppad.
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?
from cppad.
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
from cppad.
What is the test checking for? What does "$have_ar" mean? Is something missing from my system?
from cppad.
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
from cppad.
@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.
- 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 insvn:externals
. TheDependencies
file, on the other hand, lists version20170000
so with agit
clone, building with theget.depedencies
script, you get a different version. There seems to be a genuine bug in2015000
that was fixed by2017000
. - 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, sinceconfigure.ac
inmaster
contains the commandhave_ar = yes
rather than the actual check for the existence ofar
(see here). SoCppAD_HAVE_AR
is now alwaystrue
, whether thear
command is available or not. - 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 thear
command to the path doesn't fix the problem. Thear
command is not the right command to use when building withcl
. The command that should be used is thelib
command. This is the reason for the patches applied tolibtool
which are applied in theCOIN_PATCH_LIBTOOL_CYGWIN
incoin.m4
here. It's possiblear
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
forcl
.
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.
from cppad.
-
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.
from cppad.
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
from cppad.
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!
from cppad.
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!
from cppad.
@tkralphs, I emailed you at [email protected]. Is this still a good email address for you?
from cppad.
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:
- You are still hard-coding the presence of
ar
(see above). I think deleting the linehave_ar='yes'
fromconfigure.ac
will allow the build to go through, but I'm not exactly clear on what you're doing in yourconfigure.ac
. It seems like a better fix would be to defineAR
to belib
in the case ofcl
(lib
is the archive program used by Visual Studio). - After this, there seems to be an error in
makefile.am
. Whenar
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.
from cppad.
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.
from cppad.
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.
from cppad.
I think this issue has been fixed ?
If so, would you please close it.
from cppad.
I'm checking it. Was there a specific fix? I didn't find one.
from cppad.
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
from cppad.
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.
from cppad.
Is this still an open problem ?
from cppad.
from cppad.
Can you capture the command used to execute the CppAD configure
; i.e., what options are in the command.
from cppad.
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.
from cppad.
It would help me if you could specify a script for me to run that would generate the problem.
from cppad.
from cppad.
@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.
from cppad.
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).
from cppad.
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
from cppad.
from cppad.
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 ?
from cppad.
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.
from cppad.
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.
from cppad.
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
from cppad.
I was using gcc in the build above. I need to get 'cl' and ifort in my path.
from cppad.
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.
from cppad.
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.
from cppad.
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
from cppad.
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.
from cppad.
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 ?
from cppad.
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).
from cppad.
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.
from cppad.
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 ?
from cppad.
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.
from cppad.
Do you know how to launch in the Visual Studio debugger an executable generated by the make test
command ?
from cppad.
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.
from cppad.
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.
from cppad.
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).
from cppad.
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
from cppad.
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
from cppad.
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.
from cppad.
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 ?
from cppad.
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?
from cppad.
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
?
from cppad.
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
``
from cppad.
I added ar-lib
to the top source directory, but it still trys to use g++ when I build without the --enable-msvc flag.
from cppad.
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.
from cppad.
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 ?
from cppad.
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
from cppad.
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
from cppad.
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.
from cppad.
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!
from cppad.
I will create a 20210000 release on the first of next year.
from cppad.
from cppad.
Related Issues (20)
- Undefined reference to temp_file HOT 2
- ipopt and cppad tests HOT 11
- Problem to Link with CppAD and Ipopt HOT 16
- CppAD::cg::CGException: what(): GreaterThanZero cannot be called for non-parameters HOT 5
- Compiler warnings from use of bitwise '|' and '&' for bool arguments HOT 5
- Potential build mistake in third party tool in use of NDEBUG flag - CppAD compiled in Release HOT 13
- Static library for non-windows builds HOT 2
- User's Guide URL on README.md 404s HOT 8
- bin/get_colpack.sh Script Error HOT 6
- Exception thrown in val_graph optimizer HOT 3
- Name of function is cleared after val_graph optimization
- License question about the meaning of EPL-2.0 OR GPL-2.0-or-later HOT 3
- CppAD exception while running parallel loop HOT 13
- About Eigen. I can't store the scalar result of a matrix operation at the index location of another std::vector or Eigen::Vector. HOT 5
- Could NOT find GOOGLEHASH (missing: GOOGLEHASH_COMPILE) HOT 4
- make check_cppad_ipopt Failure HOT 14
- No installed conda 'base' environment found on macos-latest.
- ADFun::optimize gives compile error with std::complex HOT 4
- Errors when build with latest version of cppad and cppadcg on 3 years old code. HOT 8
- Error when acquiring sparsity pattern of a base2ad function HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cppad.