coin-or / Bonmin

Basic Open-source Nonlinear Mixed INteger programming
https://coin-or.github.io/Bonmin
Eclipse Public License 1.0
118 stars 22 forks source link

Installation help? #41

Open qih08 opened 1 year ago

qih08 commented 1 year ago

Hi!

I'm having some trouble installing bonmin, and I was wondering if anyone had advice.

I first tried installing from source, and linking our existing installations of ipopt and cbc, using a similar set of flags as I used for ipopt: ./configure --prefix /target/path --enable-static \ --with-ipopt \ --with-ipopt-cflags=-I/path/to/ipopt/include \ --with-ipopt-lflags="-lipopt -L/path/to/ipopt/lib" \ --with-cbc \ --with-cbc-cflags=-I/path/to/cbc/include \ --with-cbc-lflags="-lCbc -L/path/to/cbc/lib"

However, this results in: checking for COIN-OR package CoinDepend... not given: No package 'cbc' found No package 'osi-clp' found No package 'ipopt' found configure: error: Required package Cbc or Ipopt not available.

I tried various combinations of putting the -L flags into LDFLAGS, but it always seems to give this error.

I then tried using coinbrew: ./coinbrew build bonmin --prefix /target/path \ --with-asl-cflags=-I/path/to/asl \ --with-hsl-cflags=-I/path/to/hsl/include \ --with-lapack-cflags=-I/path/to/openblas/include \ --with-lapack-lflags=-lopenblas \ --with-hsl-lflags="-lopenblas -lcoinhsl -ldl" \ --with-asl-lflags=-lcoinasl \ LDFLAGS="-L/path/to/hsl/lib -L/path/to/openblas/lib" \ --no-third-party --static --tests none

(The CoinUtils unit test seemed to fail, so I tried tests none just to get the installation going.)

But oddly, this only produces cbc and clp executables.

Any advice or tips would be appreciated!

svigerske commented 1 year ago

It looks like you try to build the last release or branch stable/1.8.

The first one fails because the configure in the main directory expects different flags than the one in the Bonmin subdirectory. The one in the main dir is of little use since the move to GitHub. You could try with running configure from the Bonmin subdirectory directly. However, there is no flag to specify different paths for the headers of Ipopt and Cbc. There is just a --with-coindepend-incdir to specify one directory with headers for both Ipopt and Cbc. It may work better if you set your PKG_CONFIG_PATH to include the directories with the .pc files of your Ipopt and Cbc installations (/path/to/ipopt/lib/pkgconfig, /path/to/cbc/lib/pkgconfig).

The second one fails because the flags to specify ASL libs and header directory are --with-asl-lib and --with-asl-incdir.

A lot has changed in the buildsystem for the master branch of Bonmin. The flags you use seem to correspond to that.

tkralphs commented 1 year ago

As @svigerske pointed out, your flags are a bit mangled. I would definitely recommend building with coinbrew, but you shouldn't need any of the --with-* flags unless you are trying to link to something already installed. But maybe that was your intention, as you specified --no-third-party, which disables coinbrew's automatic download, build, and install mechanism for the third-party project like ASL. If that is your intention, it's fine, but then you would need to use the correct flags for linking to projects like ASL.

One thing @svigerske didn't point out directly is that the reason you didn't get an executable is probably just that ASL is required in order to produce an executable, since Bonmin reads instances in .nl format only. It's likely it was not found and this would not cause the build to fail, it would only cause no executable to be produced. If you run coinbrew with -v 4, you will see the output of configure and that should indicate whether ASL is successfully found or not.

Sorry for the README being a bit out of date. There are very few volunteers taking care of these projects and not much bandwidth to update, but I am trying to get to it.

qih08 commented 1 year ago

Thanks for your comments!

I had been trying to use the configure file in the main directory (https://github.com/coin-or/Bonmin/blob/master/configure) indeed and took the flags out of there. I'm a bit confused about where to find the Bonmin subdirectory though -- I don't see one in this repo? (I feel like I'm missing something obvious here...)

For the coinbrew installation, I had used the --no-third-party flag because when I ran it directly, it failed at installing blas: make: *** No rule to make targetdnrm2.f', needed by dnrm2.lo'. Stop. As there was already an openblas installation that worked for ipopt, I thought I'd just use that. (Though I'm realizing that given the change in the --with-* flag structure, many of the softwares have been changed enough that that might be a bad assumption.) We also only have a license for a specific version of HSL, so I didn't want it to try and build HSL.

Once I fixed the ASL flags, when I run coinbrew with -v 4, I do see the line checking for COIN-OR package ASL... yes

I think I'm failing to properly link openblas though, as when coinbrew gets to the Clp build, it gives me a libCoinUtils.so: undefined reference todgetrs_'error. I am giving coinbrew the flags--with-lapack-incdir=/path/openblas-0.3.20/include --with-lapack-lib="-L/path/openblas-0.3.20/lib"`. I know for the ipopt installation, I had needed to give lapack the -lopenblas flag, but if I put it into the --with-lapack-lib flag, it doesn't know what to do with it. Is this flag supposed to go elsewhere?

Thanks again for your help!

tkralphs commented 1 year ago

If you successfully linked to openblas with Ipopt, it should also work with other projects and yes, it is better to just use openblas if you have it.

when coinbrew gets to the Clp build, it gives me a libCoinUtils.so: undefined reference to dgetrs_ error

[Edit: This is incorrect!] This linking error should only arise if Clp does successfully find openblas and try to use it, but CoinUtils didn't when it was built. This in turn should only happen if they are built with different configure arguments, which shouldn't happen with coinbrew unless CoinUtils is successfully built and installed with one set of arguments, while Clp fails and then Clp is re-built with a different set of arguments.

It's safest to uninstall everything after a failed build, before trying again, for this reason. The best practice to avoid this kind of issue is to first build and install in a separate temporary directory until you get everything working. You would do

coinbrew build Bonmin -b ~/tmp_build_install -p

(along with any other arguments needed). The -b is to specify the build directory and the -p is for the install directory, which defaults to the build directory if you don't specify anything. The advantage of this is that deleting ~/tmp_build_install will completely uninstall everything and get you back to a clean slate easily.

If you build in a temporary directory, then once the build succeeds, you can re-build again without specifying a local build directory. Or it's also actually fine to just leave in a local directory and just add to your PATH and LD_LIBRARY_PATH variables.

Anyway, to fix your current situation, it will most likely be OK to just delete the build directory and rebuild from scratch. Check the configure output to make that each project is finding openblas. And yes, if you need the flag -lopenblas then specify it in --with-lapack-lib="-L/path/openblas-0.3.20/lib -lopenblas"

qih08 commented 1 year ago

I triple checked and I made sure to delete the installation directory (as specified by --prefix) and the build directory (subdirectory build) before running coinbrew, but it still gives the error with Clp (libCoinUtils.so: undefined reference to dgetrs_). I then tried with a different directory specified via the -b flag, and it runs into the same error.

In the configure output of CoinUtils, I see: checking whether -lblas has BLAS... yes: -lblas checking for COIN-OR package Lapack... yes

Does that imply the CoinUtils did find the openblas installation, or should I check somewhere else as well?

Note that I can't seem to give the -lopenblas flag to --with-lapack-lib -- I get /bin/ld: cannot find -lopenblas.

Thanks!

tkralphs commented 1 year ago

Does that imply the CoinUtils did find the openblas installation, or should I check somewhere else as well?

Looks like it found some BLAS installed, but it linked with -lblas, not -lopenblas. Are you sure that there is a libopenblas.so in /path/openblas-0.3.20/lib?

As for the problem with the undefined reference to dgetrs_ from libCoinUtils.so, thinking about it again now, I was completely off on my explanation. Sorry! But I don't actually have a solid theory for what exactly is going on. If you could do the build from scratch in a clean build directory with high verbosity (-v 4) and attach the full output here, then it will be much easier to diagnose.

qih08 commented 1 year ago

Oh hm, the /path/openblas-0.3.20/lib contains libopenblas64_.so.

In this build attempt, I shifted to building couenne instead of bonmin, as that is the final desired application for which bonmin is a dependency. I've also redacted the full paths to /path/. Here is the output; I directed both stdout and stderr to it: configure.txt

Thanks again!

tkralphs commented 1 year ago

OK, now things are clearer. I should have been able to see what was going on from what you'd already said, but I haven't been working much with these projects recently and I answered too quickly. The missing symbols are from Lapack, not Blas, and if you check the link line where the failure occurs, it is not in fact linking to Lapack, only Blas, so the failure makes sense.

Because you specified --with-lapack-lib, the configure script did not look for a system-installed Lapack library, as it did for BLAS. And since you were missing the -llapack, it also did not find the lapack library provided by openblas, as you intended. In my own openblas installation, I have both libblas.so and liblapack.so. It seems yours are named differently, but whatever .so file you have, that's what you need to link to, e.g., -lopenblas64_ for your Blas and something similar for Lapack.

To keep things simple and get something working, I would just leave off the --with-lapack-lib and -with-lapack-incdir and see if you can build successfully that way. It seems likely since you have a system-installed Blas and probably have Lapack, too. If that works, then you can try to link to Blas and Lapack from your openblas installation.

qih08 commented 1 year ago

Ah, I understand now!

I feel like this is SO CLOSE now -- on the bonmin install step, I got the error:

../CbcBonmin/.libs/libbonminampl.so: undefined reference to `Ipopt::AmplSuffixHandler::GetIntegerSuffixValues(std::string, Ipopt::AmplSuffixHandler::Suffix_Source) const'
../CbcBonmin/.libs/libbonminampl.so: undefined reference to `Ipopt::AmplOptionsList::AmplOption::AmplOption(std::string, Ipopt::AmplOptionsList::AmplOptionType, std::string)'
../CbcBonmin/.libs/libbonminampl.so: undefined reference to `Ipopt::AmplTNLP::get_discrete_info(int&, int&, int&, int&, int&, int&, int&, int&) const'
../CbcBonmin/.libs/libbonminampl.so: undefined reference to `Ipopt::AmplSuffixHandler::AmplSuffixHandler()'
../CbcBonmin/.libs/libbonminampl.so: undefined reference to `Ipopt::AmplSuffixHandler::GetNumberSuffixValues(std::string, Ipopt::AmplSuffixHandler::Suffix_Source) const'
../CbcBonmin/.libs/libbonminampl.so: undefined reference to `vtable for Ipopt::AmplOptionsList'
../CbcBonmin/.libs/libbonminampl.so: undefined reference to `Ipopt::AmplTNLP::AmplTNLP(Ipopt::SmartPtr<Ipopt::Journalist const> const&, Ipopt::SmartPtr<Ipopt::OptionsList>, char**&, Ipopt::SmartPtr<Ipopt::AmplSuffixHandler>, bool, Ipopt::SmartPtr<Ipopt::AmplOptionsList>, char const*, char const*, char const*, std::string*)'
../CbcBonmin/.libs/libbonminampl.so: undefined reference to `Ipopt::AmplTNLP::set_active_objective(int)'

I thought this might be because I was using an older version of ASL, but I just updated to ASL 1.4.4, and I got the same error. Do you know what might be causing this error?

Just to recap, I am now using coinbrew with --no-third-party --tests none and linking in ASL and HSL, so coinbrew is handling both ipopt and bonmin installs.

svigerske commented 1 year ago

These symbols should be defined in Ipopt library libipoptamplinterface.so. There seem to be some issue with that lib or with linking against that lib.

qih08 commented 1 year ago

Hmm, so I see that in libipoptamplinterface.so, it does seem to have those objects (or at least grep matches the names). I tried adding the lib folder of the install directory to $LD_LIBRARY_PATH, tried using the same build/install folder, and tried adding the lib folder as input to coinbrew in LDFLAGS (LDFLAGS=-L/path/to/lib).

I'm not sure what else to try... Could it be a version issue? Coinbrew seems to select Ipopt 3.12.12 and Bonmin 1.8.8.

tkralphs commented 1 year ago

This shouldn't be hard to track down. What is the output of ldd libbonminampl.so?

qih08 commented 1 year ago
    linux-vdso.so.1 =>  (0x00002aaaaaacd000)
    libbonmin.so.4 => /builddir/Bonmin/1.8.8/src/CbcBonmin/.libs/libbonmin.so.4 (0x00002aaaaaef0000)
    libCbcSolver.so.3 => /installdir/lib/libCbcSolver.so.3 (0x00002aaaab1ee000)
    libCbc.so.3 => /installdir/lib/libCbc.so.3 (0x00002aaaab4f1000)
    libCgl.so.1 => /installdir/lib/libCgl.so.1 (0x00002aaaab802000)
    libOsiClp.so.1 => /installdir/lib/libOsiClp.so.1 (0x00002aaaabb13000)
    libClpSolver.so.1 => /installdir/lib/libClpSolver.so.1 (0x00002aaaabd5d000)
    libClp.so.1 => /installdir/lib/libClp.so.1 (0x00002aaaabfc7000)
    libOsi.so.1 => /installdir/lib/libOsi.so.1 (0x00002aaaac37e000)
    libCoinUtils.so.3 => /installdir/lib/libCoinUtils.so.3 (0x00002aaaac5d1000)
    libbz2.so.1 => /lib64/libbz2.so.1 (0x00002aaaac907000)
    libz.so.1 => /lib64/libz.so.1 (0x00002aaaacb17000)
    libipopt.so.1 => /installdir/lib/libipopt.so.1 (0x00002aaaacd2d000)
    libcoinhsl.so.0 => not found
    liblapack.so.3 => /lib64/liblapack.so.3 (0x00002aaaad159000)
    libblas.so.3 => /lib64/libblas.so.3 (0x00002aaaad8b6000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaadb0f000)
    libcoinasl.so.1 => /asl/1.4.4/lib/libcoinasl.so.1 (0x00002aaaadd13000)
    libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00002aaaadfb5000)
    libm.so.6 => /lib64/libm.so.6 (0x00002aaaae2bd000)
    libc.so.6 => /lib64/libc.so.6 (0x00002aaaae5bf000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002aaaae98d000)
    /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)
    libcoinhsl.so.0 => not found
    libcoinhsl.so.0 => not found
    libgfortran.so.3 => /lib64/libgfortran.so.3 (0x00002aaaaeba3000)
    libquadmath.so.0 => /lib64/libquadmath.so.0 (0x00002aaaaeec5000)

It doesn't seem to be looking for libipoptamplinterface.so! (Also doesn't seem to be able to find the HSL installation... Hm... Though that libcoinhsl exists in the path I'm passing to --with-hsl-lib)

tkralphs commented 1 year ago

I kind of assumed you must not be linking to libipoptamplinterface.so. There are any number of reasons this could be happening and debugging it should not be hard (if you know what you're looking for). However, the easiest thing right now is just to build the entire thing from scratch once more in a newly created build directory with -v 4 and attach the entire output as a file. Also include the coinbrew fetch and build commands in their entirety. From that output, I think I can figure out what's going wrong.

qih08 commented 1 year ago

Here is the output: output.txt

The command I was running was ./coinbrew build couenne@0.5.8 -b temp_build --with-asl-incdir=/asl/1.4.4/include/coin/ThirdParty --with-hsl-lib="-lcoinhsl -L/coinhsl/lib" --with-hsl-incdir=/coinhsl/include --with-asl-lib="-lcoinasl -L/asl/1.4.4/lib" --no-third-party --tests none -v 4.

Thank you!

tkralphs commented 1 year ago

I assume that the same thing happened?

svigerske commented 1 year ago

There is a misunderstanding what ASL means in Bonmin's configure:

AC_COIN_CHECK_PACKAGE(ASL, [ipoptamplinterface], [BonminAmplInterfaceLib])

The best would probably be to not name the ipoptamplinterface lib "ASL".

svigerske commented 1 year ago

Could you try again with Bonmin@stable/0.8 ? I renamed the thing in configure.ac, so your setting of --with-asl-lib shouldn't confuse it anymore.

tkralphs commented 1 year ago

Wow, great catch @svigerske! I guess this was never triggered before because everyone is just using our third party package.

tkralphs commented 1 year ago

In case it's unclear to @qih08, if you are going to build Couenne, you would need to do coinbrew build Couenne@0.5 .... This will then get the stable branch of Couenne, which depends on the stable branch of Bonmin.

qih08 commented 1 year ago

Ah, I may be missing something, but coinbrew build Couenne@0.5 ... (or Couenne@0.5.8) both seem to try to build Bonmin 1.8.8. Is there a way to force it to use a particular version of Bonmin? I also tried deleting the Bonmin folder to force it to fetch a new copy, but it just fetches Bonmin releases/1.8.8 still.

tkralphs commented 1 year ago

Hmm, that shouldn't be the case. The Dependencies for stable/0.5 are here:

https://github.com/coin-or/Couenne/blob/stable/0.5/Dependencies

and you can see stable/1.8 listed there for Bonmin. If you can do coinbrew fetch Couenne@0.5 in a clean directory and send the output, I'll see what's going on. I just did and it fetches the right version of Bonmin for me.

qih08 commented 1 year ago

Ah, after cleaning out the directory and rerunning it properly picked up the other bonmin release (though isn't it 1.8?). I got another ASL error (asl.h: No such file or directory).

But! I realized I had not tried to build couenne/0.5 with coinbrew handling the ThirdParty packages, so I tried coinbrew build couenne@0.5 --prefix /path, and it actually didn't hit the blas error (maybe a different version was pulled?).

However, in that case I run into an issue with ASL, where the certificates have expired on the website it pulls from. I resolved this in my manual build of ASL, by modifying get.ASL to have the no-check-certificates. It seems that if I do this in the coinbrew directory, subsequent build attempts will say Skipping ThirdParty/ASL; the install directory will only have binaries for cbc and clp, which our previous discussion indicates that ASL was not linked properly.

(Side note: it worries me a little that I had to add --tests=none or CoinUtils hits the error

Testing CoinModel
lt-unitTest: /coinbrew-2.0/CoinUtils/CoinUtils/test/CoinModelTest.cpp:447: void CoinModelUnitTest(const string&, const string&, const string&): Assertion `numErr== 0' failed.

)

So I guess to recap the current situation:

Thank you both so much for your help!

svigerske commented 1 year ago

Maybe I fixed that issue about asl.h not being found in Bonmin/stable/1.8. You could try that again.

The get.ASL in the version you use falls back to ampl.com if www.coin-or.org doesn't work. If both fail with certificate issues, then that is strange. I guess you could first do a coinbrew fetch, then run the get.ASL with your modifications manually, and then do the coinbrew build.

tkralphs commented 1 year ago

Side note: it worries me a little that I had to add --tests=none or CoinUtils hits the error

The failure of the CoinUtils unit test is a known issue that we should try to address, but given that all tests are passing on Github Actions, I'm not overly concerned. I would, however. do --tests main so that the unit test of the main project is run at the end. This should be fine.

But! I realized I had not tried to build couenne/0.5 with coinbrew handling the ThirdParty packages, so I tried coinbrew build couenne@0.5 --prefix /path, and it actually didn't hit the blas error (maybe a different version was pulled?).

This is the most trouble-free path. Almost everything you're running into is because of not using the ThirdParty wrappers. It would be helpful if you always paste in the exact coinbrew command for anything you try, since it'a not always clear from the description exactly what you did, which makes it hard to debug. I assume by this you mean you removed --no-third-party? In this case, it would download source for Blas and Lapack and build and link to those versions. This should always work, but it is better in general to use the system Blas and Lapack. You can always do `--skip 'ThirdParty/Blas ThirdParty/Lapack' to skip only those projects.

Once I get around to creating a config.yaml for both Bonmin and Couenne, then we'll be able to specify dependencies as "optional" and "recommended" so that Blas and Lapack will be skipped out of the box by default.

However, in that case I run into an issue with ASL, where the certificates have expired on the website it pulls from

As @svigerske said, this is very strange, since it first tries to pull from Github, which certainly can't have an expired certificate. I just tried here and it works fine. Can you try running the unmodified script again and if it fails, post the output here?

It seems that if I do this in the coinbrew directory, subsequent build attempts will say Skipping ThirdParty/ASL;

I'm not 100 percent sure from what you said, but this is probably because coinbrew creates a file .build after successfully running get.ASL, which tells coinbrew that ASL is ready to be built. The best thing to do is to modify the get.ASL script and then let coinbrew do the download, as @svigerske suggested. But if you want, you can also run touch .build in the the ThirdParty/ASL directory and this will force it to try to build next time coinbrew is run.

qih08 commented 1 year ago

SUCCESS!! Thanks both of you so much for all your help! Below are some details in case it is useful for anyone in the future / if you notice something I was doing non-recommended.

If I run coinbrew build couenne@0.5 --prefix /path/couenne/0.5 --tests main in a totally clean coinbrew installation, I get:

##################################################
### Fetching ThirdParty/ASL stable/1.4 
##################################################

Cloning into 'ThirdParty/ASL'...
remote: Enumerating objects: 1308, done.
remote: Counting objects: 100% (184/184), done.
remote: Compressing objects: 100% (72/72), done.
remote: Total 1308 (delta 117), reused 175 (delta 112), pack-reused 1124
Receiving objects: 100% (1308/1308), 3.81 MiB | 0 bytes/s, done.
Resolving deltas: 100% (856/856), done.

Running script for downloading the source code for the ASL

Downloading the source code from www.coin-or.org...
--2023-04-03 21:20:07--  https://www.coin-or.org/BuildTools/ASL/solvers-64919f75f.tgz
Resolving www.coin-or.org (www.coin-or.org)... 130.127.206.21
Connecting to www.coin-or.org (www.coin-or.org)|130.127.206.21|:443... connected.
ERROR: cannot verify www.coin-or.org's certificate, issued by ‘/C=US/O=Let's Encrypt/CN=R3’:
  Issued certificate has expired.
To connect to www.coin-or.org insecurely, use `--no-check-certificate'.

Downloading from COIN-OR failed, trying ampl.com...
--2023-04-03 21:20:07--  https://ampl.com/netlib/ampl/solvers.tgz
Resolving ampl.com (ampl.com)... 172.67.6.96, 104.22.0.94, 104.22.1.94, ...
Connecting to ampl.com (ampl.com)|172.67.6.96|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://portal.ampl.com/~dmg/netlib/ampl/solvers.tgz [following]
--2023-04-03 21:20:08--  https://portal.ampl.com/~dmg/netlib/ampl/solvers.tgz
Resolving portal.ampl.com (portal.ampl.com)... 174.142.60.87
Connecting to portal.ampl.com (portal.ampl.com)|174.142.60.87|:443... connected.
ERROR: cannot verify portal.ampl.com's certificate, issued by ‘/C=US/O=Let's Encrypt/CN=R3’:
  Issued certificate has expired.
To connect to portal.ampl.com insecurely, use `--no-check-certificate'.
Download failed...exiting
Unpacking the source code...
gzip: solvers-64919f75f.tgz: No such file or directory

It seems it does not try to pull from Github? I'm not sure why this would be. I've been using the coinbrew from https://github.com/coin-or/coinbrew/archive/refs/tags/v2.0.tar.gz.

I then cleaned the directory and did coinbrew fetch couenne@0.5 (this ran into the same error about certificates), edited get.ASL with --no-check-certificate, ran get.ASL manually, touch .build, and finally ran coinbrew build couenne@0.5 --prefix /path/couenne/0.5 --tests main. This worked! (I may experiment with the --skip 'ThirdParty/Blas ThirdParty/Lapack' option later, thanks!)

Just to note in case someone else wants to build with external ASL, with ./coinbrew build couenne@0.5 --prefix /path/couenne/0.5 --with-asl-incdir=/path/asl/1.4.4/include/coin/ThirdParty --with-hsl-lib="-lcoinhsl -L/path/coinhsl/lib" --with-hsl-incdir=/path/coinhsl/include --with-asl-lib="-lcoinasl -L/path/asl/1.4.4/lib" --no-third-party --tests main @svigerske's commit fixed the issue with linking in external ASL! Bonmin built! But then couenne runs into the error

../.libs/libCouenne.so: undefined reference to `Bonmin::AmplInterface::readAmplNlFile(char**&, Ipopt::SmartPtr<Bonmin::RegisteredOptions>, Ipopt::SmartPtr<Ipopt::OptionsList>, Ipopt::SmartPtr<Ipopt::Journalist>, std::string*)'
../.libs/libCouenne.so: undefined reference to `Bonmin::AmplInterface::AmplInterface()'
../readnl/.libs/libCouenneReadnl.so: undefined reference to `Bonmin::AmplTMINLP::AmplTMINLP(Ipopt::SmartPtr<Ipopt::Journalist const> const&, Ipopt::SmartPtr<Bonmin::RegisteredOptions>, Ipopt::SmartPtr<Ipopt::OptionsList>, char**&, Ipopt::AmplSuffixHandler*, std::string const&, std::string*)'
../.libs/libCouenne.so: undefined reference to `Bonmin::AmplInterface::~AmplInterface()'
../.libs/libCouenne.so: undefined reference to `typeinfo for Bonmin::AmplInterface'
../.libs/libCouenne.so: undefined reference to `Bonmin::AmplInterface::AmplInterface(Bonmin::AmplInterface const&)'

So something on the couenne side seems like it needs an update.

tkralphs commented 1 year ago

OK, yeah, the primary download URL in ASL 1.4 is our old download location on www.coin-or.org, which should still work ... except that is also seems to have an expired certificate! We switched to Github in ASL 2.0, but it seems that both Bonmin and Couenne still depend on 1.4. Thanks for alerting us to this.

svigerske commented 1 year ago

The Couenne error is probably the same issue as with Bonmin. Try now again, for couenne@0.5.

The old ASL 1.4 should still work and I would hesitate to mix the new-buildsystem ASL 2.0 with the old-buildsystem Bonmin 1.8 (or Couenne 0.5). It seems to be rather a problem on the qih08's machine that Let's Encrypt certificates aren't accepted. Works for me.