Re: Re: Windows/MSVC: install_builtins, octave_interpreter_ready not found

[Christoph.Mayer]

I propose the following patch (see below):

        1. including builtins.h in builtins.cc via mkbuiltins

Without this, the symbol install_builtins gets not exported into octinterp.dll

        2. adding more OCTINTERP_API macros to toplev.h

At the moment I need only do_octave_atexit(), but for more flexibility I'd like 
to have access all global variables and functions in toplev.h

I have now succeeded in compiling parts of octave-2.9.13 (octave.exe, 
liboctave, octinterp, libcruft) under MSVC2005 after manually adding      
#define WINVER 0x500
        #define _WIN32_WINNT 0x500
to libcruft/misc/cquit.c

With octave-2.9.17, I had to manually add to Makeconf,
FLIBS  += -lf2c
FFLAGS += -MD
(I do not yet know how to manipulate configure.in)


Best Regards

Christoph


Index: mkbuiltins
===================================================================
RCS file: /cvs/octave/src/mkbuiltins,v
retrieving revision 1.24
diff -u -r1.24 mkbuiltins
--- mkbuiltins  13 Oct 2007 01:42:21 -0000      1.24
+++ mkbuiltins  28 Nov 2007 14:54:39 -0000
@@ -43,6 +43,7 @@
 #include "defun.h"
 #include "oct-obj.h"
 #include "variables.h"
+#include "builtins.h"
 
 #if defined (quad)
 #undef quad
Index: toplev.h
===================================================================
RCS file: /cvs/octave/src/toplev.h,v
retrieving revision 1.61
diff -u -r1.61 toplev.h
--- toplev.h    27 Nov 2007 20:14:41 -0000      1.61
+++ toplev.h    28 Nov 2007 14:54:39 -0000
@@ -36,21 +36,21 @@
 class tree_statement_list;
 class charMatrix;
 
-extern void
+extern OCTINTERP_API void
 clean_up_and_exit (int) GCC_ATTR_NORETURN;
 
-extern void recover_from_exception (void);
+extern OCTINTERP_API void recover_from_exception (void);
 
 extern int main_loop (void);
 
-extern void
+extern OCTINTERP_API void
 do_octave_atexit (void);
 
 // Current command to execute.
-extern tree_statement_list *global_command;
+extern OCTINTERP_API tree_statement_list *global_command;
 
 // Pointer to parent function that is currently being evaluated.
-extern octave_function *curr_parent_function;
+extern OCTINTERP_API octave_function *curr_parent_function;
 
 // TRUE means we are ready to interpret commands, but not everything
 // is ready for interactive use.


> -----Ursprüngliche Nachricht-----
> Von: Michael Goffioul [mailto:address@hidden
> Gesendet: Montag, 26. November 2007 15:05
> An: Mayer, Christoph
> Cc: address@hidden; Octave Maintainers List
> Betreff: Re: Windows/MSVC: install_builtins, octave_interpreter_ready not
> found
> 
> On 11/26/07, address@hidden <address@hidden> wrote:
> > Dear List,
> >
> > I have an C++ octave application running under Linux which uses multiple
> > octave interpreters.
> >
> > While it works under Linux, when I try to compile it under Windows using
> > MSVC++2005 and the octave-2.9.16 Windows built, the linker cannot
> > resolve the following symbols:
> >
> > bool octave_interpreter_ready (toplev.h)
> > void intall_builtins(void)
> >
> > See below for the compiler/linker flags.
> >
> > Is there a way to access these global variables and functions?
> 
> Unfortunately, not with the version you have.
> 
> > I have noted that some functions and global variables are declared using
> > OCTINTERP_API and those are accessible under MSVC.
> 
> The problem is that unlike mingw, MSVC does not export symbols by
> default; so you need to tell explicitely which symbols are exported in a
> DLL; this is usually achieve using a XXX_API macro, which expand to
> __declspec(dllexport) or __declspec(dllimport).
> 
> When I ported octave to MSVC, I added export macros "on-demand"
> such that I could compile octave and octave-forge. So not all possible
> octave symbols are available and it may happen that sometimes people
> will need a symbol that is not exported. Accessing those symbols
> requires to recompile octave, so there's no way with the version you
> have.
> 
> I propose the attached patch to solve your problem. One "hard" job would
> be to identify in the full source tree all symbols that need to be
> exported
> and are part of octave API, and tag them with the appropriate macro.
> But this is not something I gonna do....
> 
> Michael.
> 
> src/ChangeLog:
> 
> 2007-11-26  Michael Goffioul <address@hidden>
> 
>     * toplev.h, builtins.h: export more symbols [Win32/MSVC]
> 
> 
> Index: src/builtins.h
> ===================================================================
> RCS file: /cvs/octave/src/builtins.h,v
> retrieving revision 1.18
> diff -c -p -r1.18 builtins.h
> *** src/builtins.h      12 Oct 2007 21:27:29 -0000      1.18
> --- src/builtins.h      26 Nov 2007 13:57:18 -0000
> *************** along with Octave; see the file COPYING.
> *** 23,29 ****
>   #if !defined (octave_builtins_h)
>   #define octave_builtins_h 1
> 
> ! extern void install_builtins (void);
> 
>   #endif
> 
> --- 23,29 ----
>   #if !defined (octave_builtins_h)
>   #define octave_builtins_h 1
> 
> ! extern OCTINTERP_API void install_builtins (void);
> 
>   #endif
> 
> Index: src/toplev.h
> ===================================================================
> RCS file: /cvs/octave/src/toplev.h,v
> retrieving revision 1.59
> diff -c -p -r1.59 toplev.h
> *** src/toplev.h        12 Oct 2007 21:27:34 -0000      1.59
> --- src/toplev.h        26 Nov 2007 13:57:18 -0000
> *************** extern octave_function *curr_parent_func
> *** 52,61 ****
> 
>   // TRUE means we are ready to interpret commands, but not everything
>   // is ready for interactive use.
> ! extern bool octave_interpreter_ready;
> 
>   // TRUE means we've processed all the init code and we are good to go.
> ! extern bool octave_initialized;
> 
>   class
>   octave_call_stack
> --- 52,61 ----
> 
>   // TRUE means we are ready to interpret commands, but not everything
>   // is ready for interactive use.
> ! extern OCTINTERP_API bool octave_interpreter_ready;
> 
>   // TRUE means we've processed all the init code and we are good to go.
> ! extern OCTINTERP_API bool octave_initialized;
> 
>   class
>   octave_call_stack