Opened 13 years ago

Closed 13 years ago

#30 closed defect (fixed)

Problem building MSVC v8

Reported by: hpwalton Owned by: andreasw
Priority: minor Component: configuration tests
Version: 0.5 Keywords:
Cc:

Description

I'm trying to start the binary build for MSVC v8.

I'm able to build using MSVisualStudio/v8/Cbc/Cbc.sln using: devenv Cbc.sln /Build Release 2>&1 > c:\opensource\buildtools\Cbc_release_out.txt

I have cygwin as well. I am able to do this: ./configure CXX=CL.EXE LD=LINK.EXE then: make 2>&1 | tee make.out Here is the tail of make.out. Linking seems to fail:

...
[ lots of build warnings and other messages ]
...
/bin/sh ../libtool --tag=CXX --mode=link CL.EXE  -O  -DNDEBUG      -o libCoinUtils.la -rpath /cygdrive/c/opensource/Cbc/lib  CoinBuild.lo CoinDenseVector.lo CoinError.lo CoinFactorization1.lo CoinFactorization2.lo CoinFactorization3.lo CoinFactorization4.lo CoinFileIO.lo CoinIndexedVector.lo CoinLpIO.lo CoinMessage.lo CoinMessageHandler.lo CoinModel.lo CoinModelUseful.lo CoinModelUseful2.lo CoinMpsIO.lo CoinPackedMatrix.lo CoinPackedVector.lo CoinPackedVectorBase.lo CoinPostsolveMatrix.lo CoinPrePostsolveMatrix.lo CoinPresolveDoubleton.lo CoinPresolveDual.lo CoinPresolveDupcol.lo CoinPresolveEmpty.lo CoinPresolveFixed.lo CoinPresolveForcing.lo CoinPresolveHelperFunctions.lo CoinPresolveImpliedFree.lo CoinPresolveIsolated.lo CoinPresolveMatrix.lo CoinPresolvePsdebug.lo CoinPresolveSingleton.lo CoinPresolveSubst.lo CoinPresolveTighten.lo CoinPresolveTripleton.lo CoinPresolveUseless.lo CoinPresolveZeros.lo CoinShallowPackedVector.lo CoinWarmStartBasis.lo CoinWarmStartDual.lo  
mkdir .libs
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries
false cru .libs/libCoinUtils.a  CoinBuild.obj CoinDenseVector.obj CoinError.obj CoinFactorization1.obj CoinFactorization2.obj CoinFactorization3.obj CoinFactorization4.obj CoinFileIO.obj CoinIndexedVector.obj CoinLpIO.obj CoinMessage.obj CoinMessageHandler.obj CoinModel.obj CoinModelUseful.obj CoinModelUseful2.obj CoinMpsIO.obj CoinPackedMatrix.obj CoinPackedVector.obj CoinPackedVectorBase.obj CoinPostsolveMatrix.obj CoinPrePostsolveMatrix.obj CoinPresolveDoubleton.obj CoinPresolveDual.obj CoinPresolveDupcol.obj CoinPresolveEmpty.obj CoinPresolveFixed.obj CoinPresolveForcing.obj CoinPresolveHelperFunctions.obj CoinPresolveImpliedFree.obj CoinPresolveIsolated.obj CoinPresolveMatrix.obj CoinPresolvePsdebug.obj CoinPresolveSingleton.obj CoinPresolveSubst.obj CoinPresolveTighten.obj CoinPresolveTripleton.obj CoinPresolveUseless.obj CoinPresolveZeros.obj CoinShallowPackedVector.obj CoinWarmStartBasis.obj CoinWarmStartDual.obj
make[2]: *** [libCoinUtils.la] Error 1
make[2]: Leaving directory `/cygdrive/c/opensource/Cbc/CoinUtils/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/cygdrive/c/opensource/Cbc/CoinUtils'
make: *** [all-recursive] Error 1

Change History (5)

comment:1 Changed 13 years ago by andreasw

  • Status changed from new to assigned

Hi Philip,

Writing the reply below, I realized that the problem might simply be that the configure script doesn't like the extension '.EXE' for the compiler and linker executables... ;) Please try it again, but specify CL and LINK instead of CL.EXE and LINK.EXE. If that works let me know and I will adapt the configure scripts in the future.

Otherwise:

It is possible that there were some old objects lying around?

please do the following:

  1. Obtain a clean copy of the code
  2. Do a VPATH configuration: In the base directory of the package (i.e., where the basic configure script is), do
    mkdir build
    cd build
    ../configure CXX=cl
    make
    make test
    make install
    

That should work...

If it doesn't, please attach the CoinUtils?/config.log file to this ticket.

comment:2 Changed 13 years ago by lou

Well, Philip hooked me into this, and the problems go deep. Autoconf is not at its best with cl. There's a deep problem with exit(); see this ref for an explanation. This is fixed in autoconf 2.60. Maybe it's time to start thinking seriously about upgrading from 2.59.

Rather than forcing cl and link as command line flags, a cleaner solution is to change the code in coin.m4. Reorder the search list to AC_PROG_CC and AC_PROG_CXX, and do some other tweaks. I'm proposing (see BuildTools posting) that we change the usage of enable-doscompile so that it takes a value. Possible values would be cygwin, mingw, msvc, and possibly msys (Kipp recommends MSYS as a build environment).

comment:3 Changed 13 years ago by lou

I've been able to get the DyLP project (DyLP + CoinUtils + OSI) to build, link, and run the OSI unitTest. I'm using autoconf 2.61, and starting a bash shell from the MSVC cmd.exe shell that's set up when MSVC installs. Search path order is important. In particular, libtool needs to find Gnu sort, not MS sort. But if link is ever called directly, MS link needs to be found before Gnu link (which does file links!). Will test changes on other platforms over the next day or so.

comment:4 Changed 13 years ago by andreasw

  • Priority changed from major to minor

What is the status on this?

Looking at the original output it seems that there is a problem with the archiver; since it reads false cru. This should be either 'ar' or something else with 'lib'. The value false means that libtool doesn't have that correct value; I had implemented automatic changes of the libtool script that correct this. I think that the original problem was caused by the fact that this fix was only done for CXX=cl, but not for CXX=CL.EXE.

Actually, I think, CXX=cl.exe will now work, but CXX=CL[.EXE] might still fail.

I don't think this has anything to do with the "exit()" problem of autoconf with the CL compiler. In the coin.m4 tests, I worked around this issue by giving a first argument to AC_TRY_LINK, as in

                    AC_TRY_LINK([void $4();],[$4()],
                                [AC_MSG_RESULT(yes)],
                                [AC_MSG_RESULT(no)
                                 AC_MSG_ERROR([Cannot find symbol $4 with $2])])

This way, no automatic pretext is added to the C program (which would contain that exit declaration), but instead the program text only declares the function that we want to find.

This seems to overcome the problem for the CL compiler. Nevertheless, it would be nice to switch to newer autoconf, so that this workaround is no longer required.

comment:5 Changed 13 years ago by andreasw

  • Resolution set to fixed
  • Status changed from assigned to closed

I think the problem has been resolved. But I just realized that CC=CL will still not work in upper case... Will change that too now. But I will close ticket.

Note: See TracTickets for help on using tickets.