Re: [OS] Problems - Making COIN-OS 2.3.2 on win32

[Gus Gassmann]

On 10 Feb 2011 at 19:59, Mike Steglich wrote:

> Hi,
>
> I tried to build Clp, Cgl and Cbc in the way suggested by Stefan. But I obtained the same errors.
> Additionally I downloaded CBC 2.6.2 and followed the instructions given in the INSTALLATION file. I regret to say that I got the same errors.
>
> It seems, that is not possible to build Cbc 2.6.2 using Msys and MinGw on Windows7. I will check these issues on an other PC to proof this hypothesis.

The current version of OS shows Cbc 2.7 in its depencies file. I wonder if it is
just a version problem. The undefined reference errors point at missing
include file directories on the compile or link command. If the location of the
code changed between versions, this is exactly the behaviour I would expect
to see.

_______________________________________________
OS mailing list
O...@list.coin-or.org
http://list.coin-or.org/mailman/listinfo/os

[Lou Hafer]

Mike,

For what it's worth, I have seen this behaviour in the distant past.
Far enough back that I'm afraid I can't point you to any details. There are a
number of programs that have the potential to give problems: find, sort, and
link come to mind. From hazy memory, the order of directories in your search
path should be something like (Visual Studio stuff);(Msys stuff);(standard
Windows stuff) in order to do builds with cl/link. Occasionally you may need to
do an explicit override. Looks like you're building with GCC, so you don't have
to worry about the Visual Studio stuff.

I guess this is the danger of using find to locate the individual
subdirectories under Cgl/src. Unfortunately, I don't see an AC_PROG_FIND macro
to locate a working find.

Lou

[Lou Hafer]

Folks,

I've sent Mike a tweaked version of Cgl/configure (too big to attach
here) that substitutes ls for find. This should sidestep the PATH issue. I've
also made the change in Cgl/trunk. If this works for Mike, we can propagate it
into the current Cgl/stable. (The down side is that this wires in an assumption
about the shape of the cut generator subdirectories. At present, that's not a
problem.)

Here's the diff against Cgl/configure in release/0.56.2. (The echo of
PATH is just to confirm the diagnosis.)

Lou

zaphod: diff configure configure.tweaked
25371,25376c25371,25376
< for file in `find . -name Makefile.in`; do
< if test $file != ./Makefile.in; then
< newdir=`echo $file | sed -e s%/Makefile.in%% | sed -e s%^./%% `
< CGL_SUBDIRS="$CGL_SUBDIRS $newdir"
< CGL_SUBLIBS="$CGL_SUBLIBS $newdir/lib${newdir}.la"
< fi
---
> echo "$as_me:$LINENO: PATH at Cgl subdir check: $PATH" >&5
> echo $ECHO_N "PATH at subdir Cgl check: $PATH" >&6
> for file in `ls */Makefile.in`; do
> newdir=`echo $file | sed -e s%/Makefile.in%% | sed -e s%^./%% `
> CGL_SUBDIRS="$CGL_SUBDIRS $newdir"
> CGL_SUBLIBS="$CGL_SUBLIBS $newdir/lib${newdir}.la"

[Lou Hafer]

Mike,

The output from the patched configure script I sent you makes it clear
(I've broken it into one line per PATH element):

PATH at subdir Cgl check:

/c/Program Files/Parallels/ParallelsTools/Applications:
/c/Windows/system32:
/c/Windows:
/c/Windows/System32/Wbem:
/c/Windows/System32/WindowsPowerShell/v1.0/:
/c/Programme/ILOG/OPL63/bin/x86_win32:
/mingw/bin:
/bin:
/c/qt-sdk/qt/bin:
/c/programme/cmpl

Somehow, something that you have installed on your system is putting the Windows
binary directories (the ones starting with /c/Windows) in front of the Msys and
Mingw binary directories (/mingw/bin, /bin). By patching the configure script to
use ls instead of find, I got you past the first problem. But the make output
that you sent me ends with these lines:

(cd .libs/libCgl.lax/libCglAllDifferent.a && ar x
/home/mike/documents/COIN-OS/Cgl/src/CglAllDifferent/.libs/libCglAllDifferent.a)
libtool: link: ERROR: object name conflicts:
.libs/libCgl.lax/libCglAllDifferent.a//home/mike/documents/COIN-OS/Cgl/src/CglAl
lDifferent/.libs/libCglAllDifferent.a

When I compare the various CGLxxx variables in your config.log with ones that I
get here on Solaris, yours all look reasonable. So I'm going to take a wild
guess, based on some past experience: Libtool uses sort, and it's finding the
Windows sort instead of the Msys (unix) sort. The two are not compatible.
Unlike make, libtool does not recognise that the error lies with sort; it just
fails to work correctly. But the next thing I would try is to rearrange your
PATH so that the Windows binary directories come *after* /mingw/bin and /bin.

This will probably break something else that you have installed. I think
some of the others working on this have said that MinGW puts its own binary
directories first at installation. My suspicion is that something else that you
install after MinGW is rearranging your path to what it thinks is correct. If
you install Parallels after MinGW, it'd be at the top of my list of suspects.
But the only way to be sure is to check PATH after installing MinGW and then
after installing each additional program.

As with all diagnosis at a distance, your mileage may vary. But one of
the folks with MinGW installed should be able to say how PATH should look
immediately after the MinGW install.

Lou