From help-octave-request at bevo dot che dot wisc dot edu Tue Dec 12 22:52:39 2000 Subject: Re: mkoctfile From: Mumit Khan To: Andy Adler cc: help-octave Date: Tue, 12 Dec 2000 22:52:35 -0600 (CST) On Tue, 12 Dec 2000, Andy Adler wrote: > I was thinking about this recently, and I wondered if it > would be possible to use the approach used in the Perl > module Win32::API > > http://search.cpan.org/doc/ACALPINI/Win32-API-0.20/API.html > > This allows you to load and call arbirary functions > in windows dlls from perl. I looked at the source, and it doesn't > seem to be that hairy, although it has some assember in it. It does do the job if you have a DLL on Windows and know what function to call, and it's a real neat way doing that. However, you still need a "well-formed" DLL so that you can call the functions, and moreover it has no way of dealing with global variables that are exported from a DLL. I do remember looking at this way back when it first surfaced, and thought about using it for another purpose. The problem with dynamically linked Octave functions is a bit different, and IMO the simplest approach is to add the proper macros to the code to export/import the global variables and do it right just once. We definitely want uniformity in how you build .oct files on various platforms. It's really not a hard problem, just an annoying one, and one that will take someone who really needs it make it go. I needed a few .oct files, and I decided that it was simply easier to deal with *huge* oct files than finishing what I had started (which is now lost unfortunately). I only used Octave/win32 when my previous laptop didn't do Linux very well, but that problem went away a long time ago, and so did my motivation for spending much time on this issue. Many issues, not much time as usual. If someone is interested, I can provide some insight on what needs to be done. Here's the basic scenario: Two possible ways of building DLL version of Octave runtime: 1. One massive DLL -- this is much easier for reasons that becomes apparent once your undertake this effort. 2. Keep Octave's current library structure, and then build individual DLLs. This is tricky, since you now have both multiple dependent DLLs. If you choose [1], then the following steps at the very minimum: 1. Code inspection to figure out what, if any, Octave global variables need to be exported. If none, life gets much easier. If any, then those need to be encased in various declspec macros to export/import properly. 2. Write an export definition file. Easy. 3. Create the final DLL. Easy. If you build one large DLL, then there are some issues you need to deal with in Octave-like code-bases, and the primary one is that you can't have multiple definitions (that's ok if you split things in multiple archives, and the linker takes care of it). I don't recall if I ran into this case or not. Hmmm ... now it seems rather simple, and I wonder what kind of problems I ran into when I had tried it. I remember bringing up the issue of libtool'izing Octave, and I don't believe JWE had the time for it. The advantage there is that newer releases of libtool can create the DLLs and import libraries without adding lots of extra stuff to Octave's config and Makefiles. I go on an extended trip in 3 days, and I'll have plenty of quality "air time" (with my luck, most of that will be in airports), and perhaps I'll take Octave with me and see where I had left of. No promises, and certainly no guarantees. I may simply forget all about it by the time I leave for the airport. To be quite honest, if I had the time to work on Octave, I'd probably be doing it where I really think Octave needs it -- cross platform visualization. When I'm careful, most, if not all, of my code is portable between matlab and octave, but I still have to boot back into Windows when on the road to use Matlab to look at my results. Stinks. I see that a KDE project (Kmatplot???) works with Octave, and it does look quite nice. Too bad it's using Qt, which is non-free on Windows. Enough rant on a topic that is irrelevant in this thread. Regards, Mumit ------------------------------------------------------------- Octave is freely available under the terms of the GNU GPL. Octave's home on the web: http://www.octave.org How to fund new projects: http://www.octave.org/funding.html Subscription information: http://www.octave.org/archive.html -------------------------------------------------------------