[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WIN32 problem on liboctave/kpse.cc
From: |
John W. Eaton |
Subject: |
Re: WIN32 problem on liboctave/kpse.cc |
Date: |
Mon, 16 Nov 2009 15:32:20 -0500 |
On 16-Nov-2009, Marco Atzeri wrote:
| --- Mer 11/11/09, Marco Atzeri <address@hidden> ha scritto:
|
|
| > --- Mer 11/11/09, John W. Eaton <address@hidden>
| > ha scritto:
| >
|
| > > Data: Mercoledì 11 novembre 2009, 16:04
| > > On 11-Nov-2009, Michael Goffioul
| > > wrote:
| > >
| > > | On Wed, Nov 11, 2009 at 7:51 AM, Marco Atzeri <address@hidden>
| > > wrote:
| > > | > Hi,
| > > | > building on latest
| > > | > $ hg tip
| > > | > changeset: 9799:cfd0aa788ae1
| > > | > tag: tip
| > > | > user: John W. Eaton <address@hidden>
| > > | > date: Tue Nov 10 23:07:25 2009
| > -0500
| > > | > summary: remove reference blas and
| > lapack
| > > sources
| > > | >
| > > | > this block on liboctave/kpse.cc
| > > | > is causing win32lib.h (that does not esist) to
| > be
| > > | > included in cygwin.
| > > | >
| > > | > #if defined(__MINGW32__)
| > > | > #include <windows.h>
| > > | > #include <fcntl.h>
| > > | > #include <dirent.h>
| > > | > #elif defined(WIN32)
| > > | > #define __STDC__ 1
| > > | > #ifndef _MSC_VER
| > > | > #include "win32lib.h"
| > > | > #endif
| > > | > #endif /* not WIN32 */
| > > | >
| > > | > This fault is really new, so some of the
| > latest
| > > changesets
| > > | > caused it, but kpse.cc seems untouched from
| > > longtime
| > > | > so I am bit puzzled.
| > > |
| > > | Maybe because WIN32 is now defined under cygwin,
| > while it
| > > used
| > > | to not be defined before. Might be a configure
| > issue.
| > >
| > > What is defining WIN32 on Cygwin systems? Is GCC
| > > defining that by
| > > default now? Or is it some (unintentional) change
| > in
| > > the configure
| > > script that is doing it?
| > >
| > > jwe
|
| it seems that WIN32 is defined as on
| liboctave/lo-utils.h
|
| this piece of code is pulling "windows.h", and folllowing
| all the /usr/include/w32api/* that should not be used
| for cygwin only program.
|
| #ifdef HAVE_LOADLIBRARY_API
| #include <windows.h>
| extern "C" OCTAVE_API void * octave_w32_library_search (HINSTANCE handle,
const char *name);
| #undef min
| #undef max
| #endif
| #endif
The configure script currently has
### Dynamic linking is now enabled only if we are building shared
### libs and some API for dynamic linking is detected.
## FIXME -- a lot of the following duplicates the functionality of
## code generated by the dlopen option for LT_INIT.
LD_CXX='$(CXX)'
RDYNAMIC_FLAG=
DL_API_MSG=""
dlopen_api=false
shl_load_api=false
loadlibrary_api=false
dyld_api=false
if $SHARED_LIBS || $ENABLE_DYNAMIC_LINKING; then
## Check for dyld first since OS X can have a non-standard libdl
save_LIBS="$LIBS"
use_mach_dyld=false
AC_ARG_ENABLE(mach-dyld,
[AS_HELP_STRING([--enable-mach-dyld], [enable older Mach-O dyld
interface])],
[if test "x$enableval" = xno; then
use_mach_dyld=false;
else
use_mach_dyld=true;
fi], [])
if $use_mach_dyld; then
AC_CHECK_HEADER(mach-o/dyld.h)
if test "$ac_cv_header_mach_o_dyld_h" = yes; then
dyld_api=true
fi
elif test "$dyld_api" = false; then
AC_CHECK_LIB(dld, shl_load, [DL_LIBS=-ldld; LIBS="$LIBS $DL_LIBS"])
AC_CHECK_FUNCS(shl_load shl_findsym)
if test "$ac_cv_func_shl_load" = yes \
&& test "$ac_cv_func_shl_findsym" = yes; then
shl_load_api=true
else
AC_CHECK_LIB(wsock32, LoadLibrary, [
DL_LIBS=-lwsock32; LIBS="$LIBS $DL_LIBS"])
AC_CHECK_FUNCS(LoadLibrary)
if test "$ac_cv_func_loadlibrary" = yes; then
loadlibrary_api=true
else
## With the dlopen option, LT_INIT has already checked for
## dlopen and the -ldl library. So we just look at cache values.
if test "x$ac_cv_lib_dl_dlopen" = xyes; then
DL_LIBS=-ldl;
LIBS="$LIBS $DL_LIBS"
fi
if test "x$ac_cv_func_dlopen" = xyes \
|| test "x$ac_cv_lib_dl_dlopen" = xyes; then
AC_CHECK_FUNCS(dlsym dlerror dlclose)
if test "x$ac_cv_func_dlclose" = xyes \
&& test "x$ac_cv_func_dlerror" = xyes \
&& test "x$ac_cv_func_dlsym" = xyes; then
dlopen_api=true
else
case "$canonical_host_type" in
i[[3456]]86-*-sco3.2v5*)
LD_CXX='LD_RUN_PATH=$LD_RUN_PATH:$(octlibdir) $(CXX)'
dlopen_api=
;;
esac
fi
fi
fi
fi
fi
LIBS="$save_LIBS"
AC_SUBST(DL_LIBS)
## autoconf test for LoadLibrary appears broken. Bypass for cygwin/mingw
if $dlopen_api || $shl_load_api || $loadlibrary_api || $dyld_api; then
true
else
case "$canonical_host_type" in
*-*-cygwin* | *-*-mingw* | *-*-msdosmsvc)
loadlibrary_api=true;
;;
esac
fi
if $dlopen_api; then
DL_API_MSG="(dlopen)"
AC_DEFINE(HAVE_DLOPEN_API, 1, [Define if your system has dlopen, dlsym,
dlerror, and dlclose for dynamic linking])
OCTAVE_CXX_FLAG(-rdynamic, [RDYNAMIC_FLAG=-rdynamic])
elif $shl_load_api; then
DL_API_MSG="(shl_load)"
AC_DEFINE(HAVE_SHL_LOAD_API, 1, [Define if your system has shl_load and
shl_findsym for dynamic linking])
elif $loadlibrary_api; then
DL_API_MSG="(LoadLibrary)"
AC_DEFINE(HAVE_LOADLIBRARY_API, 1, [Define if your system has LoadLibrary
for dynamic linking])
elif $dyld_api; then
DL_API_MSG="(dyld)"
AC_DEFINE(HAVE_DYLD_API, 1, [Define if your system has dyld for dynamic
linking])
fi
if $dlopen_api || $shl_load_api || $loadlibrary_api || $dyld_api; then
ENABLE_DYNAMIC_LINKING=true
AC_DEFINE(ENABLE_DYNAMIC_LINKING, 1, [Define if using dynamic linking])
fi
fi
What is this doing? Can you find out whether this is detecting the
LoadLibrary API with the test
AC_CHECK_LIB(wsock32, LoadLibrary, [
DL_LIBS=-lwsock32; LIBS="$LIBS $DL_LIBS"])
AC_CHECK_FUNCS(LoadLibrary)
if test "$ac_cv_func_loadlibrary" = yes; then
loadlibrary_api=true
or whether it is the subsequent
## autoconf test for LoadLibrary appears broken. Bypass for cygwin/mingw
if $dlopen_api || $shl_load_api || $loadlibrary_api || $dyld_api; then
true
else
case "$canonical_host_type" in
*-*-cygwin* | *-*-mingw* | *-*-msdosmsvc)
loadlibrary_api=true;
;;
esac
fi
that is setting loadlibrary_api to true? If it is the latter, then I
think the fix is to remove *-*-cygwin* from the case statement. If it
is detecting LoadLibrary in the wsock32 library, then maybe we need to
switch the order of the tests, or disable the check on Cygwin systems?
I think this same information is computed by the LT_INIT macro, so as
the comment in configure.ac states, I would ultimately like to just
use that information and omit our (apparently duplicate) checks.
What do the libtool checks determine on your system? Do they find
LoadLibrary or dlopen?
If you're not sure, then send me your config.log file and a copy of
the messages that go to the terminal when you run the configure
script.
jwe