[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to combine several functions in a single oct-file? (2)

From: Michael Goffioul
Subject: Re: How to combine several functions in a single oct-file? (2)
Date: Mon, 13 Feb 2012 09:17:45 +0000

On Mon, Feb 13, 2012 at 6:55 AM, Lukas Reichlin
<address@hidden> wrote:
>>>>> Michael.
>>>> Hi Michael,
>>>> I like your idea of a single shared library very much. Is it possible to 
>>>> create such a library out of SLICOT upon package installation? It would be 
>>>> nice if I could link it the same way as the BLAS and LAPACK libraries.
>>>> Best regards,
>>>> Lukas
>>> PS: I would like to include the archive slicot.tar.gz [1] in my package. 
>>> Then, upon package installation, it should be unpacked and compiled to a 
>>> library I can link to. Until now, I have to add all files by hand, which is 
>>> quite ugly [2].
>>> Lukas
>>> [1] SLICOT Library
>>> [2] Makefile of the control package
>> I'd say as long as you write the appropriate Makefile, you can do
>> whatever you want.
>> Michael.
> OK, thanks. I assume I have to create something like
> ~/octave/control-2.2.5/x86_64-apple-darwin10.8.0-api-v48+/slicotlibrary.a
> Do you know the mkoctfile options to create such a library file?

If you create a static library (like slicotlibrary.a) then it will be
compiled in every oct-file you link with, there's no need to install
it. If you create a shared library (like, then you need
to install it in a platform-dependent way (on UNIX it must be
somewhere in LD_LIBRARY_PATH or equivalent, on Windows it must be in
PATH, on Mac OS X I have no idea).

An alternate solution would be to outsource the library (slicot) your
package depends on: keep only the octave-related code in your package
and let the user install slicot using their own distro-way. There are
other packages like octcdf or octproj that depend on external
libraries, but they are not included in the octave package. Of course
this works well as long as the dependent library is available on usual
distros through the common channels.

Finally, mkoctfile is not intended to build general purpose libraries,
so you'll have to do it the standard way: anyway mkoctfile is just a
wrapper around the actual compiler, adding octave-specific paths
automatically, but you wouldn't need them to compile slicot. What you
would typically do in a Makefile is something like:

CC = $(shell mkoctfile -p CC)
CXX = $(shell mkoctfile -p CXX)
F77 = $(shell mkoctfile -p F77)
DL_LD = $(shell mkoctfile -p DL_LD)
DL_LDFLAGS = $(shell mkoctfile -p DL_LDFLAGS)

CFLAGS = $(shell mkoctfile -p CFLAGS)
CXXFLAGS = $(shell mkoctfile -p CXXFLAGS)
FFLAGS = $(shell mkoctfile -p FFLAGS)

CPICFLAG = $(shell mkoctfile -p CPICFLAG)
CXXPICFLAG = $(shell mkoctfile -p CXXPICFLAG)
FPICFLAG = $(shell mkoctfile -p FPICFLAG)

%.o: %.c
        $(CC) $(CFLAGS) $(CPICFLAG) -o $@ -c $<

        $(CXX) $(CXXFLAGS) $(CXXPICFLAG) -o $@ -c $<

%.o: %.f
        $(F77) $(FFLAGS) $(FPICFLAG) -o $@ -c $< $(OBJECTS)
        $(DL_LD) $(DL_LDFLAGS) -o $@ $^

This is untested, but I hope it gives you an idea.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]