Ok, I&#39;ve made some progress in the direction Duncan suggested.<br><br>I can filter out the extra library before the postConf hook gets it.  And calling &quot;make&quot; from the hooks is pretty easy.<br><br>I&#39;ve got a hack working that does allow full build/link/install given a hardcoded path (e.g. hack).  It works by passing -Wl,-rpath=/opt/... directly through the .cabal file (ld-options).  I need to un-hardcode that directory but I can&#39;t figure out how to achieve the same effect as that ld-options from my Setup.hs (I tried adding buildProgramArgs in the buildHook but no luck yet).<br>

<br>There&#39;s also the question of how to find the install dir so that rpath can be set to it.  Unfortunately, I haven&#39;t been able to dig that out yet.  When I try to use absoluteInstallDirs via something like below, I get this error: &quot;setup: internal error InstallDirs.libsubdir&quot;<br>

<br>  putStrLn$ &quot;Install dirs: &quot; ++ show (absoluteInstallDirs desc linfo NoCopyDest)<br><br>Best,<br> -Ryan<br><br><br><br><div class="gmail_quote">On Sun, Jan 30, 2011 at 10:20 PM, Ryan Newton <span dir="ltr">&lt;<a href="mailto:rrnewton@gmail.com">rrnewton@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Thanks Duncan,<br><br>Alas, I don&#39;t think it&#39;s something I want to install globally on the users machine.  It&#39;s actually not much code, but I can&#39;t get cabal to build it directly because it chokes on the .s assembly files (which are intel syntax not AT&amp;T).  Right now I&#39;m depending on &quot;yasm&quot;.  The makefile I run just executes the commands listed at the end of this email.<br>


<br>After much random monkeying thusfar, I&#39;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&#39;m on ubuntu).  This approach is what I was trying to do in commit <a href="https://github.com/rrnewton/intel-aes/commit/0abc7d0a456ee0d818b2313184f0d253aae10e47" target="_blank">0abc7d0a456ee0d818b2</a> here:<br>


<br>   git clone git://<a href="http://github.com/rrnewton/intel-aes.git" target="_blank">github.com/rrnewton/intel-aes.git</a><br>   git checkout 0abc7d0a456ee0d818b2313184f0d253aae10e47<br><br>(Note that the makefile in cbits still needs to be run manually in that version.)<br>


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


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


<br>Cheers,<br>  -Ryan<br><br>P.S. Build commands:<br><br>gcc -fPIC -O3 -g -Iinclude/ -c src/intel_aes.c -o obj/x64/intel_aes.o<br>yasm -D__linux__ -g dwarf2 -f elf64  asm/x64/iaesx64.s -o obj/x64/iaesx64.o<br>yasm -D__linux__ -g dwarf2 -f elf64  asm/x64/do_rdtsc.s -o obj/x64/do_rdtsc.o<br>


ar -r lib/x64/libintel_aes.a obj/x64/intel_aes.o obj/x64/iaesx64.o obj/x64/do_rdtsc.o<br>gcc -shared -dynamic  -o lib/x64/libintel_aes.so obj/x64/intel_aes.o obj/x64/iaesx64.o obj/x64/do_rdtsc.o<div><div></div><div class="h5">

<br><br><br><div class="gmail_quote">
On Sun, Jan 30, 2011 at 12:22 PM, Duncan Coutts <span dir="ltr">&lt;<a href="mailto:duncan.coutts@googlemail.com" target="_blank">duncan.coutts@googlemail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


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