"Cabal ignores ld-options?" - 2011 remix

[Ryan Newton]

Thanks Duncan,

Alas, I don't think it's something I want to install globally on the users
machine.  It's actually not much code, but I can't get cabal to build it
directly because it chokes on the .s assembly files (which are intel syntax
not AT&T).  Right now I'm depending on "yasm".  The makefile I run just
executes the commands listed at the end of this email.

After much random monkeying thusfar, I'd be happy with anything that works
;-).  Is extra-lib-dirs for an executable supposed to change the search path
at runtime?  Via extra-libraries I can successfully introduce the dependency
on libFOO.so (as reported by ldd).  But the search path appears to not be
modified (without manually tweaking LD_LIBRARY_PATH -- I'm on ubuntu).  This
approach is what I was trying to do in commit
0abc7d0a456ee0d818b2<https://github.com/rrnewton/intel-aes/commit/0abc7d0a456ee0d818b2313184f0d253aae10e47>here:

   git clone git://github.com/rrnewton/intel-aes.git
   git checkout 0abc7d0a456ee0d818b2313184f0d253aae10e47

(Note that the makefile in cbits still needs to be run manually in that
version.)

"extra-libraries" is only for dynamic libs of the form "libXX.so|dylib|dll"
right?  Even if they were globally installed it doesn't help with .a libs,
does it?  The users guide says "A list of extra libraries to link with." --
at the cost of verbosity a bit of elaboration would be much appreciated ;-).

In any case, I want to try playing with the hooks that you mentioned.  But I
have at least one newbish question first.  I'm running "cabal install"
inside my package's directory and that doesn't seem to run Setup.hs.  Is
that not the way to simulate the eventual effect of a user "cabal
install"ing from hackage?

Cheers,
  -Ryan

P.S. Build commands:

gcc -fPIC -O3 -g -Iinclude/ -c src/intel_aes.c -o obj/x64/intel_aes.o
yasm -D__linux__ -g dwarf2 -f elf64  asm/x64/iaesx64.s -o obj/x64/iaesx64.o
yasm -D__linux__ -g dwarf2 -f elf64  asm/x64/do_rdtsc.s -o
obj/x64/do_rdtsc.o
ar -r lib/x64/libintel_aes.a obj/x64/intel_aes.o obj/x64/iaesx64.o
obj/x64/do_rdtsc.o
gcc -shared -dynamic  -o lib/x64/libintel_aes.so obj/x64/intel_aes.o
obj/x64/iaesx64.o obj/x64/do_rdtsc.o


On Sun, Jan 30, 2011 at 12:22 PM, Duncan Coutts <
duncan.coutts at googlemail.com> wrote:

> On Sun, 2011-01-30 at 05:20 -0500, Ryan Newton wrote:
>
> >
> > I am trying to link a ".a" file built by a separate makefile into my
> > library.  GHC has no problem with it, but I need to convince cabal to
> > do it for the package to be hackage-friendly.  There's a thread about
> > this back in 2007:
> >
> >    http://www.haskell.org/pipermail/cabal-devel/2007-April/000507.html
> >
> > Is there a method for this now, or is the state of affairs the same as
> > before?
>
> Having a Haskell package link against an external C library is
> straightforward, you just list it in the extra-libraries field. The
> external library must already be installed on the system however.
>
> Bundling a copy of the external library with a cabal package is not
> quite so easy. You will have to write code in the Setup.hs to call the
> separate makefile during the build (and perhaps extra steps at configure
> time too).
>
> Your best bet is probably to use the "simple" build system's hooks API.
> You can list the library in the extra-libraries field in the .cabal file
> but you will also need to modify the check for external libraries that
> are done in the postConf hook (since the separate .a library will not be
> available at configure time): modify the package description that gets
> passed to the postConf hook to exclude the library.
>
> Duncan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20110130/e2af490b/attachment-0001.htm>