The summary says it all, just the odd thing is that from the invocation it shouldn't error at all from what I can tell. The relevant flags to the failure are the following (repeated twice in the './configure' invocation): --with-amd-incdir=/usr/include --with-amd-lib=-lamd Then later in the logs, I see: checking if user provides library for AMD... yes checking whether symbol amd_defaults is available with AMD... no configure: error: Cannot find symbol(s) amd_defaults with AMD Which is strange, considering I can inspect the contents of '/usr/include/amd.h' and find a 'void amd_defaults (double Control [ ]) ;' on line 317. I don't really know why this would be happening. Reproducible: Always Steps to Reproduce: 1. Attempt to merge sci-libs/coinor-clp
Created attachment 918887 [details] sci-libs/coinor-clp-1.17.6-r1: build.log
Created attachment 918888 [details] sci-libs/coinor-clp-1.17.6-r1: config.log
``` configure:23381: checking whether symbol amd_defaults is available with AMD configure:23399: x86_64-pc-linux-gnu-gcc -o conftest -O2 -pipe -march=native -mtune=native -DCLP_BUILD -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -fuse-ld=mold conftest.c -lamd >&5 conftest.c: In function 'main': conftest.c:37:1: error: implicit declaration of function 'amd_defaults' [-Wimplicit-function-declaration] 37 | amd_defaults() | ^~~~~~~~~~~~ ``` C99.
The rest seems to be broken still on master: https://github.com/coin-or/Clp/blob/b92a8fd70660bbb65c0768cdd67b3e066c41e77f/configure.ac#L83.
s/rest/check/
I was wrong, see https://github.com/coin-or/Clp/commit/fea612b2327ad347b6e8aba96ff33e87b98d10fb which should fix it.
Maybe that does fix it, but only on upstream. I cannot apply that to the currently available 1.17.6-r1 in the Gentoo repos.
Sigh. The coinor-* packages really need a dedicated maintainer. IIRC they can't be upgraded independently, so you have to be ready to either fix them wholesale or start adding upper version bounds to the ebuilds we have. Not to mention that we still haven't upgraded suitesparse.
Not being able to merge it at the moment is something of a pain, since I'm trying to set up an ebuild for OpenROAD-Flow-Scripts. That requires sci-libs/lemon with USE="glpk,coin", which then in turn requires sci-libs/coinor-clp (and sci-libs/coinor-cbc. If I can help, would you mind pointing me to a good starting point?
(In reply to primalucegd from comment #9) > Not being able to merge it at the moment is something of a pain, since I'm > trying to set up an ebuild for OpenROAD-Flow-Scripts. That requires > sci-libs/lemon with USE="glpk,coin", which then in turn requires > sci-libs/coinor-clp (and sci-libs/coinor-cbc. If I can help, would you mind > pointing me to a good starting point? It depends on how much punishment you're trying to sign up for. There are a lot of coinor packages: * sci-libs/coinor-alps * sci-libs/coinor-bcp * sci-libs/coinor-bcps * sci-libs/coinor-blis * sci-libs/coinor-bonmin * sci-libs/coinor-cbc * sci-libs/coinor-cgl * sci-libs/coinor-clp * sci-libs/coinor-couenne * sci-libs/coinor-cppad * sci-libs/coinor-csdp * sci-libs/coinor-dip * sci-libs/coinor-dylp * sci-libs/coinor-flopcpp * sci-libs/coinor-mp * sci-libs/coinor-netlib * sci-libs/coinor-osi * sci-libs/coinor-sample * sci-libs/coinor-smi * sci-libs/coinor-symphony * sci-libs/coinor-utils * sci-libs/coinor-vol One saving grace is that I don't think any of these packages have been updated in a long time, so there may be other issues like this one that render them essentially non-functional. Good news! You can cross those off the list of packages to worry about. For the others, you'd have to try to figure out what the dependency graph looks like, and whether or not they work at all so that you can avoid breaking anything that currently works with a partial upgrade. (Or, if you think it would take less time, just resign yourself to a version bump for everything.) If some of those packages break when coinor-clp is upgraded, for example, then those packages would also either need to be upgraded or have an upper version bound added to their ebuilds. Then, ultimately, you would "just" be writing ebuilds for several of the packages above. The existing ebuilds are outdated however and were not great to begin, which does not work in your favor. Ideally they should build, install, and pass tests with a reasonable set of USE flags tested (all on, all off, etc.). Along the way you may have to submit PRs to fix upstream issues and incorporate your patches into the ebuilds. If you already know how to write ebuilds and are familiar with the sorts of issues you will encounter, it could only take a few days. But if not you will probably stuggle with it for a while. You CAN do them one-at-a-time if you figure out the depgraph and start at the root, but only if you go through them all and add upper version bounds to the existing ebuilds first. The problem you are avoiding is that if you add a version of (say) coinor-clp that is five years newer than the rest of the coinor-* packages, it's very unlikely that any of them will build against it, so adding the new coinor-clp could potentially "break" those other packages if they are not modified to use only the older coinor-clp.
Note that a bump itself won't fix this, I think, it'll need an eautoreconf anyway to add the patch from master.
