Hi Sergiy,

>I thought having static library to solve my problem. And I'm looking for how to build static library, but no luck.

I was also, originally trying to build a shared static library.
(I wanted to distribute a plug-in, which could be used by people knowing nothing about Haskell working on machines that did not have the Haskell Platform installed.)

Then, I happened across this nugget in section 4.11.3 of the GHC 6.12.3 User's Guide:

In principle you can use -shared without -dynamic in the link step. That means to statically link the rts all the base libraries into your new shared library. This would make a very big, but standalone shared library. Indeed this is exactly what we must currently do on Windows where -dynamic is not yet supported (see Section 11.6, “Building and using Win32 DLLs ”). On most platforms however that would require all the static libraries to have been built with -fPIC so that the code is suitable to include into a shared library and we do not do that at the moment.

That is when I changed strategies and started trying to make a shared dynamic version of my library work.

A question to the group:

With regard to:

"... that would require all the static libraries to have been built with -fPIC ...",

is this something I can do myself by re-cabaling with the proper options set in my ~/.cabal/config file, or is this more involved than that?

Thanks,
-db

On Sun, Sep 11, 2011 at 8:55 AM, Sergiy Nazarenko <nazarenko.sergiy@gmail.com> wrote:
Hi, Captain,

As far as I see you try to build static library.
If this correct, what did not work in static library?
Why do you decide compile with -dynamic option?

I was trying to build shared library. Other python library has used
some functions from library which I had written using Haskell. But
some software which we use in my company had crached after attempts to
import python module. Under pure python it works OK, but software has
crached. I thought having static library to solve my problem. And I'm
looking for how to build static library, but no luck.

Cheers,
Sergiy

On 11 September 2011 17:56, Captain Freako <capn.freako@gmail.com> wrote:
> Sergiy, Tom,
>
> Thanks for your replies.
>
> Sergiy, I was able to get this working without having to recompile my
> installed Haskell libraries.
>
> Tom, you were correct; I needed to explicitly link against the Haskell
> run-time system, as well as a few other things:
>
> I changed my ghc link options from this:
>
> HC_LOPTS = -no-hs-main -shared -package parsec -package dsp -static
>
> to this:
>
> HC_LOPTS = -shared -dynamic -package parsec-3.1.1 -package dsp -lHSrts
> -L/usr/lib/ghc-6.12.3/ -lm -lffi -lrt
>
> and things are working.
>
> (The command that builds my mixed language, shared object library,
> `libami.so', is:
>
> ghc -o libami.so $(HC_LOPTS) {object files, compiled from both C and Haskell}
> )
>
> I can understand why I'd have to explicitly link against `libHSrts',
> since I'm asking ghc for a shared object library and not an
> executable. However, I'm not sure about the following:
> - Why do I need to give the `-L/usr/lib/ghc-6.12.3/' option? (It seems
> like ghc ought to know about that, implicitly.)
> - Why do I need to explicitly link against the 3 standard C libraries:
> `m', `ffi', and `rt'? (I've never needed to do this, previously, when
> I was building/testing this project statically.)
>
> Thanks, in advance, for any insights!
>
> -db
>
>
> On 9/10/11, Sergiy Nazarenko <nazarenko.sergiy@gmail.com> wrote:
>> I've recompiled my library again and now it works without any problem.
>> Probably I made mistake somewhere.
>>
>> Cheers,
>> Sergiy
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>