<HTML><HEAD></HEAD>
<BODY dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">
<DIV>Pietro,</DIV>
<DIV>(and anyone else who may have an opinion about this)</DIV>
<DIV> </DIV>
<DIV>There’s been discussion here <A
href="https://projects.coin-or.org/BuildTools/ticket/105">https://projects.coin-or.org/BuildTools/ticket/105</A>
about explicitly linking dependencies into shared libraries (at least
optionally), which is needed for using COIN solvers in Python/Julia, packaging
for Debian, building Windows DLL’s via autotools in Cygwin/MinGW, and it can fix
some occasional linking errors. For most projects this is doable with a few
extra lines in automake. Couenne, on the other hand, appears to have a
sort-of-circular dependency in the order it builds its libraries.</DIV>
<DIV> </DIV>
<DIV>If you build with LDFLAGS=”-Wl,--no-undefined”, you can see that
Couenne/src/libCouenne depends on Couenne/src/main/libBonCouenne, but the
couenne AMPL executable also gets built in Couenne/src/main. The couenne
executable depends on Couenne/src/readnl/libCouenneReadnl, which depends on
Couenne/src/libCouenne. I can think of a few ways in which this could be
rearranged in order to resolve the problem and make building Couenne with
--no-undefined possible:</DIV>
<DIV> </DIV>
<DIV>A) Remove Couenne/src/main/libBonCouenne, and compile its three source
files into Couenne/src/libCouenne instead.</DIV>
<DIV> </DIV>
<DIV>B) Move one or more of the existing libraries and/or executables into a
different folder, so the dependency order of libBonCouenne, then libCouenne,
then libCouenneReadnl, then couenne executable can be respected without ever
having to leave and re-enter a directory (which would be rather difficult to
express in terms of Makefile dependencies).</DIV>
<DIV> </DIV>
<DIV>C) Leave Couenne/src/main/libBonCouenne where it is, but also compile its
three source files into Couenne/src/libCouenne, possibly only when the
--enable-dependency-linking option (which was recently created for this purpose)
is provided to configure.</DIV>
<DIV> </DIV>
<DIV>I went with approach C in my patch at the above link because it required
the fewest changes, however I don’t know if it is safe to duplicate code like
that in both libCouenne and libBonCouenne. Which one of these approaches do you
think would be the safest, most maintainable and least disruptive option to
consider?</DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV>Tony</DIV>
<DIV> </DIV></DIV></DIV></BODY></HTML>