cabal uses dynamic-linking for lifted-base

[山本和彦]

Hi,

When I try to install libfted-base, cabal uses dynamic-linking while
it uses static-linking for other libraries. So, I got the following
error:

% cabal install lifted-base
/usr/bin/ld: cannot find -lHSmonad-control-0.3.2.1-ghc7.7.20130616
/usr/bin/ld: cannot find -lHStransformers-base-0.4.1-ghc7.7.20130616
/usr/bin/ld: cannot find 
-lHSbase-unicode-symbols-0.2.2.4-ghc7.7.20130616

If I explicitly enable/disable dynamic-linking, lifted-base can be
installed. That is, the following two commands are valid:

% cabal install lifted-base --enable-shared
% cabal install lifted-base --disable-shared

Why dynamic-linking is used for lifted-base (only)?

--Kazu





___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Windows failures

[Simon Peyton-Jones]

Ian
This is 'sh validate" on 64bit Windows.  Rather a lot of failures.  Might you 
look?

The perf tests seem to fail because it's comparing with the *32* bit numbers, 
even though this is definitely a *64* bit laptop.   Whether the entire build 
system thinks it's a 32 bit machine, or just the testsuite, I can't tell.

Thanks

Simon


Unexpected failures:
   cabal/cabal01cabal01 [bad exit code] (normal)
   cabal/cabal04cabal04 [bad exit code] (normal)
   driver   dynHelloWorld [exit code non-0] (dyn)
   driver/dynamicToodynamicToo002 [bad stdout] (normal)
   driver/dynamicToodynamicToo003 [bad exit code] (normal)
   dynlibs  T4464 [bad exit code] (normal)
   dynlibs  T5373 [bad exit code] (normal)
   ghc-api/T7478T7478 [bad exit code] (normal)
   ghci.debugger/scriptsbreak008 [bad exit code] (ghci)
   ghci.debugger/scriptsdynbrk009 [bad exit code] (ghci)
   ghci/scripts T5975a [bad stderr] (ghci)
   llvm/should_compile  T5486 [exit code non-0] (optllvm)
   llvm/should_compile  T5681 [exit code non-0] (optllvm)
   llvm/should_compile  T6158 [exit code non-0] (optllvm)
   llvm/should_compile  T7571 [exit code non-0] (optllvm)
   llvm/should_compile  T7575 [exit code non-0] (optllvm)
   perf/compilerT1969 [stat not good enough] (normal)
   perf/compilerT3294 [stat not good enough] (normal)
   perf/compilerT4801 [stat too good] (normal)
   perf/haddock haddock.Cabal [stat not good enough] (normal)
   perf/haddock haddock.base [stat not good enough] (normal)
   perf/haddock haddock.compiler [stat not good enough] (normal)
   perf/should_run  T7797 [stat too good] (normal)
   rts  T4850 [bad stdout] (normal)
   rts  derefnull [bad exit code] (normal)
   rts  divbyzero [bad exit code] (normal)
   runghc   T7859 [bad stderr] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly01 [exit code non-0] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly02 [exit code non-0] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly03 [stderr mismatch] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly04 [exit code non-0] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly05 [stderr mismatch] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly06 [exit code non-0] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly07 [stderr mismatch] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly08 [stderr mismatch] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly09 [stderr mismatch] (normal)
   safeHaskell/check/pkg01  ImpSafeOnly10 [exit code non-0] (normal)
   safeHaskell/check/pkg01  safePkg01 [bad exit code] (normal)

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: How to build statically linking GHC?

[Ian Lynagh]

On Mon, Jun 17, 2013 at 12:12:55PM +, Stephen Paul Weber wrote:
> 
> Because I have to find and copy many files and then set up the
> library path env vars when distributing.  Especially since the
> average Haskell project relies on *many* libraries, this gets crazy
> fast.

I'm a little confused. GHC still builds static programs by default.
(well, statically-linked Haskell, dynamically-linked to C libs, like
before).


Thanks
Ian
-- 
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: status of template haskell + cross compiling plans for 7.8?

[Simon Peyton-Jones]

I have not been following the details of this debate, but there is a good 
reason why TH doesn’t work on a cross compiler. Specifically, suppose module M 
imports module X, which defines a function mkD that M calls in a splice, thus 
$(mkD “wobble”).

Currently, we compile X to X.o, and when compiling M we dynamically link X.o 
(and all the other libraries it relies on) into GHC so that we can call foo.  
Obviously X.o has to be runnable on the machine doing the compiling, so if X.o 
is for some other architecture that’s not going to work.

There is no reason in principle why one could not compile X into X.bytecode 
(along with all its dependencies), where X.bytecode is architecture 
independent. Then X.bytecode could be interpreted on any platform.  But GHC has 
no mechanism for doing this at all.   I’ve always take the view that if you 
want X.bytecode, you may as well load X.hs and translate it into bytecode.  A 
bit slower, to be sure, but maybe fast enough.  But don’t forget those 
libraries.

Anyway that’s the state of play.   Have fun!

Simon

From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org] On 
Behalf Of Carter Schonwald
Sent: 13 June 2013 22:44
To: ghc-devs@haskell.org
Subject: status of template haskell + cross compiling plans for 7.8?

Hey All,
Whats the story planned for template haskell + cross compiler support come ghc 
7.8?
I understand theres a lot of Template Haskell design underway, some of which 
will help support tools like Manuel's Inline-Objective-C work. Does this mean 
that factored out within this reorganization is a better story for cross 
compilation?

Especially since one kill "app" for the Inline-Objective-C template haskell 
work would be writing IOS applications. Though I guess that also touches on the 
need to sort out supporting "FAT" ARM binaries too, right?

This intersects with a few different large subsets of tickets, so i'm not sure 
if any single ticket is the right fora for this question.

thanks!
-Carter
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Segfault when using integer-simple

[CJ van den Berg]

On 2013-06-17 14:16, Stephen Paul Weber wrote:
> Somebody claiming to be CJ van den Berg wrote:
>> I don’t use integer-simple in my Android cross-compiler builds because I
>> ran into problems. Possibly the same problem as you. I never did
>> investigate any further though because it seemed like integer-gmp was
>> the way to go for acceptable performance anyway and the switch was not
>> difficult.
> 
> Did you have to seperately cross-compile libgmp first, or does android
> have it by default?

Yes, I have to build gmp, iconv and ncurses for Android first and then
only do I build ghc.

-- 
CJ van den Berg

mailto:c...@vdbonline.com
xmpp:neuroc...@gmail.com

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Segfault when using integer-simple

[Stephen Paul Weber]

Somebody claiming to be CJ van den Berg wrote:
I don’t use integer-simple in my Android cross-compiler builds because 
I

ran into problems. Possibly the same problem as you. I never did
investigate any further though because it seemed like integer-gmp was
the way to go for acceptable performance anyway and the switch was not
difficult.


Did you have to seperately cross-compile libgmp first, or does android have 
it by default?


--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: How to build statically linking GHC?

[Stephen Paul Weber]

Somebody claiming to be Simon Peyton-Jones wrote:

Interesting.  Why "super-annoying"?


Because I have to find and copy many files and then set up the library path 
env vars when distributing.  Especially since the average Haskell project 
relies on *many* libraries, this gets crazy fast.  Distributing to sane 
systems like Debian (where I could just set dependencies) would be fine, but 
for, say, blackberry app dev or windows or mac, it just gets in the way.


In fact, the static haskell librarie, dynamic C libraries approach GHC took 
was a major selling point when my company was choosing what platform to 
target for our blackberry development.


--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

shared libraries for profiling

[山本和彦]

Hi,

I seems to me that shared libraries for profiling are not installed.
For example, let's see the base library:

% cd lib/ghc-7.7.20130616/base-4.7.0.0
% ls -1 libHSbase*
libHSbase-4.7.0.0.a
libHSbase-4.7.0.0-ghc7.7.20130616.so*
libHSbase-4.7.0.0_p.a

A static library for profiling is installed, but there is not a
corresponding dynamic library.

I'm suffering from this because I cannot take profiling for my program
with GHC head.

Is this a bug?

--Kazu

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: How to build statically linking GHC?

[Simon Peyton-Jones]

Interesting.  Why "super-annoying"?

Simon

| -Original Message-
| From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org]
| On Behalf Of Stephen Paul Weber
| Sent: 16 June 2013 21:05
| To: ghc-devs@haskell.org
| Subject: How to build statically linking GHC?
| 
| What's the correct way, on GHC head, to get it to build libraries in the
| way
| GHC does now (so that they are statically linked into binaries) instead
| of
| the new-but-super-annoying dynamic linking?  Do I just
| DYNAMIC_BY_DEFAULT=NO
| in my build.mk?
| 
| --
| Stephen Paul Weber, @singpolyma
| See  for how I prefer to be contacted
| edition right joseph
| 
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs