[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: Lukas Reichlin
Subject: Re: How to combine several functions in a single oct-file? (2)
Date: Mon, 13 Feb 2012 11:40:30 +0100

On 13.02.2012, at 10:17, Michael Goffioul wrote:

> 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 $<
> %.o:
>        $(CXX) $(CXXFLAGS) $(CXXPICFLAG) -o $@ -c $<
> %.o: %.f
>        $(F77) $(FFLAGS) $(FPICFLAG) -o $@ -c $<
>        $(DL_LD) $(DL_LDFLAGS) -o $@ $^
> This is untested, but I hope it gives you an idea.
> Michael.

Thank you very much for your explanations, Michael. I think I'll discuss the 
options with one of my mentoring profs, as I am a neophyte when it comes to 
makefiles. What I already know: For the sake of user friendliness, I want to 
keep the control package self-containing, i.e. installation by "pkg install 
-forge control" without external libraries.

If I create a static library (like slicotlibrary.a), will the oct-file include 
the entire static library or just those parts which are needed? Is this related 
to the "code stripping" option?

Best regards,

reply via email to

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