So, did the problem go away after you updated those packages ? On Sep 8, 2011 2:36 AM, "Sergiy Nazarenko" wrote:

Hi David!

I've got same problem. As I see that happens before I've updated following packages. I needed it because I compile ghc702. mtl transformers regex-base regex-compat regex-posix hslogger network parsec hslogger HUnit MissingH datetime

If this information helps you to figure out this errors.

Cheers, Sergiy

On 6 September 2011 18:52, David Banas wrote:

...

Hi all,

I'm trying to build a shared, dynamic library for use with a C program. I'm getting an `undefined symbol' error, when I try to run that C program, and was hoping that the last line in the output, below, might mean something to someone. I include the entire output of a `make rebuild' command, below, hoping that, maybe, I just have my command line options a little wrong.

Thanks! -db

dbanas@dbanas-eeepc:~/prj/haskell/AMIParse/trunk$ make rebuild make clean make[1]: Entering directory `/home/dbanas/prj/haskell/AMIParse/trunk' rm -f *.hi *.o *.out ami_test *.so make[1]: Leaving directory `/home/dbanas/prj/haskell/AMIParse/trunk' make all make[1]: Entering directory `/home/dbanas/prj/haskell/AMIParse/trunk' gcc -I/usr/lib/ghc-6.12.3/include/ -g -fPIC -c -o ami_test.o ami_test.c gcc -rdynamic -o ami_test ami_test.o -ldl ghc -c ApplicativeParsec.hs -cpp -package parsec-3.1.1 -package dsp -dynamic -fPIC ghc -c AMIParse.hs -cpp -package parsec-3.1.1 -package dsp -dynamic -fPIC ghc -c ExmplUsrModel.hs -cpp -package parsec-3.1.1 -package dsp -dynamic -fPIC ghc -c AMIModel.hs -cpp -package parsec-3.1.1 -package dsp -dynamic -fPIC gcc -I/usr/lib/ghc-6.12.3/include/ -g -fPIC -c -o ami_model.o ami_model.c rm -f libami.so ghc -o libami.so -shared -dynamic -package parsec-3.1.1 -package dsp AMIParse.o AMIModel.o ami_model.o AMIModel_stub.o ApplicativeParsec.o ExmplUsrModel.o make[1]: Leaving directory `/home/dbanas/prj/haskell/AMIParse/trunk' dbanas@dbanas-eeepc:~/prj/haskell/AMIParse/trunk$ ./ami_test test.ami /usr/lib/ghc-6.12.3/ghc-prim-0.2.0.0/libHSghc-prim-0.2.0.0-ghc6.12.3.so: undefined symbol: stg_newByteArrayzh

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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 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

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 Guidefile:///usr/share/doc/ghc6-doc/html/users_guide/using-shared-libs.html#id262... : 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 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 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

On Sun, Sep 11, 2011 at 10:56, Captain Freako wrote:

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.)

The first is because GHC doesn't link its libraries using -L and basenames, but full path names. Since you used a basename, you also have to use -L to tell it how to expand the basename. The second is because those libraries are needed by libHSrts, and since you linked that explicitly you need to link its dependencies explicitly as well. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms