Building from source alone didn't help, but building from source
together with the following extra lines to .cabal/config worked:
extra-lib-dirs: /usr/lib
extra-lib-dirs: /opt/local/lib
This is not an ideal solution because this means that any OS X library
will shadow the corresponding Macports
On Mon, Dec 28, 2009 at 9:03 AM, Aaron Tomb at...@galois.com wrote:
On Dec 22, 2009, at 9:36 PM, wren ng thornton wrote:
Aaron Tomb wrote:
I've come across the issue with iconv, as well.
The problem seems to be that some versions of iconv define iconv_open and
some related functions as
On Dec 22, 2009, at 9:36 PM, wren ng thornton wrote:
Aaron Tomb wrote:
I've come across the issue with iconv, as well.
The problem seems to be that some versions of iconv define
iconv_open and some related functions as macros (that then call
libiconv_open, etc.), and some versions of
On Dec 21, 2009, at 5:03 PM, Thomas Schilling wrote:
It's probably just the search path ordering, no? I.e., if you add
something on the command line or in .cabal/config it gets added to
the beginning of the search path. Then again, there are cases where
you'd want the macports version
On Dec 22, 2009, at 10:39 , Aaron Tomb wrote:
On Dec 21, 2009, at 5:03 PM, Thomas Schilling wrote:
It's probably just the search path ordering, no? I.e., if you add
something on the command line or in .cabal/config it gets added to
the beginning of the search path. Then again, there are
On Dec 22, 2009, at 9:33 AM, Brandon S. Allbery KF8NH wrote:
On Dec 22, 2009, at 10:39 , Aaron Tomb wrote:
On Dec 21, 2009, at 5:03 PM, Thomas Schilling wrote:
It's probably just the search path ordering, no? I.e., if you add
something on the command line or in .cabal/config it gets added
On Tue, 2009-12-22 at 07:39 -0800, Aaron Tomb wrote:
Do we need some more flexible options to GHC, giving users more
control on the ordering of libraries on the linker command line?
I don't think there is any single ordering that will work. Different
packages need libs from different
Aaron Tomb wrote:
I've come across the issue with iconv, as well.
The problem seems to be that some versions of iconv define iconv_open
and some related functions as macros (that then call libiconv_open,
etc.), and some versions of iconv have exported functions for
everything. In particular,
Hi
I thought I'd record my upgrade exerience (so far) in case anyone else
finds it useful, and (more selfishly) in case anyone has some helpful
advice. Summary of situation
* I got 6.12 working.
* It took a lot of fumbling around.
* The eventual fix (renaming
On Mon, Dec 21, 2009 at 4:32 AM, Conor McBride
co...@strictlypositive.org wrote:
I thought I'd record my upgrade exerience (so far) in case anyone else
finds it useful, and (more selfishly) in case anyone has some helpful
advice. Summary of situation
You just described what I went through last
On Mon, Dec 21, 2009 at 1:38 PM, Tom Tobin korp...@korpios.com wrote:
On Mon, Dec 21, 2009 at 4:32 AM, Conor McBride
co...@strictlypositive.org wrote:
I thought I'd record my upgrade exerience (so far) in case anyone else
finds it useful, and (more selfishly) in case anyone has some helpful
not sure if this helps, but try:
# ports share lib export
export CPATH=~/local/include
export LIBRARY_PATH=~/local/lib
export LD_LIBRARY_PATH=~/local/lib
export DYLD_LIBRARY_PATH=~/local/lib
replace ~/local/ with your ports path
On Tue, Dec 22, 2009 at 5:43 AM, Tom Tobin korp...@korpios.com
On Mon, Dec 21, 2009 at 3:43 PM, Tom Tobin korp...@korpios.com wrote:
This time the install died on HJScript:
**
[ 2 of 26] Compiling HJScript.Monad ( src/HJScript/Monad.hs,
dist/build/HJScript/Monad.o )
src/HJScript/Monad.hs:51:10:
A pattern match on a GADT requires -XGADTs
I've come across the issue with iconv, as well.
The problem seems to be that some versions of iconv define iconv_open
and some related functions as macros (that then call libiconv_open,
etc.), and some versions of iconv have exported functions for
everything. In particular, the iconv
On Dec 21, 2009, at 17:39 , Aaron Tomb wrote:
The problem seems to be that some versions of iconv define
iconv_open and some related functions as macros (that then call
libiconv_open, etc.), and some versions of iconv have exported
functions for everything. In particular, the iconv bundled
On Dec 21, 2009, at 2:44 PM, Brandon S. Allbery KF8NH wrote:
On Dec 21, 2009, at 17:39 , Aaron Tomb wrote:
The problem seems to be that some versions of iconv define
iconv_open and some related functions as macros (that then call
libiconv_open, etc.), and some versions of iconv have
2009/12/22 Aaron Tomb at...@galois.com
On Dec 21, 2009, at 2:44 PM, Brandon S. Allbery KF8NH wrote:
On Dec 21, 2009, at 17:39 , Aaron Tomb wrote:
The problem seems to be that some versions of iconv define iconv_open and
some related functions as macros (that then call libiconv_open, etc.),
On Mon, Dec 21, 2009 at 4:05 PM, Antoine Latter aslat...@gmail.com wrote:
This one I can help with. You need to modify the .cabal file for
HJScript slightly. To do this:
cabal unpack HJScript
cd HJScript-0.4.5
${EDITOR} HJScript.cabal
And then add 'GADTs' to the 'Extensions:' list.
On Mon, Dec 21, 2009 at 8:41 PM, Tom Tobin korp...@korpios.com wrote:
On Mon, Dec 21, 2009 at 4:05 PM, Antoine Latter aslat...@gmail.com wrote:
This one I can help with. You need to modify the .cabal file for
HJScript slightly. To do this:
cabal unpack HJScript
cd HJScript-0.4.5
On Mon, 2009-12-21 at 10:32 +, Conor McBride wrote:
QUESTION: Is the sensible upgrade path to build cabal-install 0.8 with
your old GHC, before installing 6.12? Does this even work?
Yes and yes.
Anyhow, I've got 6.12 and I need cabal-install 0.8. Can I find it?
Note that it is now on
20 matches
Mail list logo
