x:xs) = k x (foldr k z xs)
Now I am quite demanding of my compiler, and in particular I expect it
to make a more informed choice here. Is there a good way of making an
informed choice here? Up to what length of the list is it a good idea
to do this? And can we implement it? Maybe simply with a f
On Sat, 2015-03-07 at 22:18 +1100, Sean Seefried wrote:
> Hi all,
>
> Can anyone explain the following problem I'm having?
>
> I'm currently writing a game in Haskell. When I produce a plain old
> executable (for local testing) it's about 23M. However, when
Hi all,
Can anyone explain the following problem I'm having?
I'm currently writing a game in Haskell. When I produce a plain old
executable (for local testing) it's about 23M. However, when I create a
static lib using the -staticlib flag it is 54M.
Why the dis
;
> On the paralllel list, edkso shares with us a single commit that adds all
> the requested features as a user land lib
>
> https://github.com/haskell-distributed/distributed-static/commit/d2bd2ebca5a96ea5df621770e98bfb7a3b745bc7
>
> @tweag folks, please do not write personal atta
indeed! Thanks erik!
On the paralllel list, edkso shares with us a single commit that adds all
the requested features as a user land lib
https://github.com/haskell-distributed/distributed-static/commit/d2bd2ebca5a96ea5df621770e98bfb7a3b745bc7
@tweag folks, please do not write personal attacks
d had time to digest it all - I thought I would just
> highlight a minor technicality.
>
> On Fri, Jan 24, 2014 at 11:19 AM, Facundo Domínguez
> wrote:
>> Looking up static references
>>
>>
>> `unstatic` is implemented as a function which
Hello,
I'd just like to say I haven't gone over every discussion in this
thread and had time to digest it all - I thought I would just
highlight a minor technicality.
On Fri, Jan 24, 2014 at 11:19 AM, Facundo Domínguez
wrote:
> Looking up static references
> ==
to solve those problems using TH
alone in a way that does not impact user friendliness and static
checking of invariants in any way.
> The existing GHC release already have a huge workload getting releases
> out the door and adding to that workload without adding manpower and
> resources would
emotely serializable values, i.e. that have an
instance of class Serializable.
2. none of the above have a Serializable instance, and are hence not
"send"-able.
When it comes to sending closures capturing any of the above types of
values, the reasoning goes like this:
3. a closure in
ablePtrs, etc). My approach
is to solve this dynamically by exception handling. I can imagine that
there is a sensible combination of RTS support with a suitable type
class framework (Static, for one), but lazy evaluation, especially lazy
I/O
y outside of GHC and if GHC
needs a few small additional features, they can be added.
> The `static e` form could as well be a piece of Template Haskell, but
> making it a proper extension means that the compiler can enforce more
> invariants and be a bit more helpful to the user.
Once i
ts raised by Mathieu in his last email as
> (1a), (1b) and (2) still hold.
>
> Here's a use case for (2):
>
> module Communicate(run)
>
> import Control.Distributed.Process
>
> f :: Int -> Int
> f = id
>
> runSend :: Process ()
> runSend = send someone (
t
f = id
runSend :: Process ()
runSend = send someone (static f)
runExpect :: Int -> Process Int
runExpect n = fmap (($ n) . unstatic) expect
If any program tries to use runExpect, it would fail at runtime
because it would fail to find `f`, because `f` is not exported and
therefore a symbol f
Theres actually a missing piece of information in this thread: what are the
example computations that are being sent?
My understanding is that erlang has not way to send file handles, shared
variables, Tvars, Mvars, memory mapped binary files, GPU code / memory
pointers , and other fun unportable t
pretty much as user friendly and easy to use as Erlang is.
>
Exactly!
>a) I don't know that it's possible from Template Haskell to detect
> and warn the user when dependent modules have not been compiled into
> dynamic object code or into static code with the right flags.
&g
On Tue, Jan 28, 2014 at 7:53 AM, Mathieu Boespflug wrote:
> On Sat, Jan 25, 2014 at 7:12 PM, Carter Schonwald
> wrote:
> > 1) you should (once 7.8 is out) evaluate how far you can push your ideas
> wrt
> > dynamic loading as a user land library.
> > If you can't make it work as a library and ca
les have not been compiled into
dynamic object code or into static code with the right flags.
b) It's very convenient in practice to be able to send not just
`f` if `f` is a global identifier, but in general `e` where `e` is any
closed expression mentioning only global names. That
To address the concerns about static linking and portability, there is
also the alternative of of using the RTS linker in those platforms
that need it.
In many aspects, neither linker makes a big difference to us. We are
going with the system's dynamic linker mainly because GHC team has
expr
e point.
Anything that reduces the amount of Template Haskell required to work with
Cloud Haskell is a "good thing (tm)" IMO. Not that I mind using TH, but the
programming model is currently quite awkward from the caller's perspective,
since you've got to (a) create a Stati
On Sun, Jan 26, 2014 at 1:43 PM, Tim Watson wrote:
> In Erlang, I can rpc/send *any* term and evaluate it on another node. That
> includes functions of course. Whether or not we want to be quite that
> general is another matter, but that is the comparison I've been making.
>
Note that Erlang gets
x27;m sure that the core GHC support is there if you actually dig
> into the apis! And they do this in a distributed systems context, sans CH.
>
We have a pull request from Edsko that melds hs-plugins support with static, as
per the original proposal's notes, so this seems like a coroll
rk in progress on specing out a proper (and sound :) ) static
values type extension for ghc, that will be usable perhaps in your your
case (though by dint of being sound, will preclude some of the things you
think you want). BUT, any type system changes need to actually provide
safety. My motivati
the only thing that we are proposing to add to the compiler is
the syntactic form "static e". Contrary to the presentation in the
paper, the 'unstatic' function can be implemented entirely as library
code and does not need to be a primop. Moreover, we do not need to
piece toget
On Fri, Jan 24, 2014 at 12:19 PM, Facundo Domínguez <
facundo.doming...@tweag.io> wrote:
> In principle, only symbols in shared libraries can be found. However,
> the dynamic linker is able to find symbols in modules that are linked
> statically if GHC is fed with the option -optl-Wl,--export-dyna
course, just ship source (or some intermediate representation), but
that would also require compiler infrastructure to be installed on the target.
> 2) how does it provide more type safety than the current TH based approach?
> (I've seen Tim and others hit very very gnarly bugs in clo
tive to the remoteTable functions
> in the distributed-static package.
>
Agreed - this is vital!
> 2. It must not change the build scheme used for Haskell programs. A
> collection of .o files produced from Haskell source code should still
> be possible to link with the system li
hard coded hopefully into both programs in a way that
it means the same thing". I've had many educational conversations with
2) how does it provide more type safety than the current TH based approach?
(I've seen Tim and others hit very very gnarly bugs in cloud haskell based
upon the
Hello,
With the support of Tweag I/O, Mathieu and I have been assembling
a design proposal for the language extension for Static values that
will take Cloud Haskell a big step forward in usability. Please, find
the proposal inlined below.
We are looking forward to discuss its feasibility
gt;> On 08/10/2010 03:23, Alexander Dunlap wrote:
> >>>
> >>>> I recently upgraded my Arch Linux system to glibc 2.12 and static
> >>>> binaries compiled with GHC 6.12.3 all fail with the message
> >>>> "mkTextEncoding: invalid argume
On Mon, Oct 11, 2010 at 2:11 AM, Simon Marlow wrote:
> On 10/10/2010 05:22, Alexander Dunlap wrote:
>>
>> On Fri, Oct 8, 2010 at 12:46 AM, Simon Marlow wrote:
>>>
>>> On 08/10/2010 03:23, Alexander Dunlap wrote:
>>>
>>>> I recently
On 10/10/2010 05:22, Alexander Dunlap wrote:
On Fri, Oct 8, 2010 at 12:46 AM, Simon Marlow wrote:
On 08/10/2010 03:23, Alexander Dunlap wrote:
I recently upgraded my Arch Linux system to glibc 2.12 and static
binaries compiled with GHC 6.12.3 all fail with the message
"mkTextEnc
On Fri, Oct 8, 2010 at 12:46 AM, Simon Marlow wrote:
> On 08/10/2010 03:23, Alexander Dunlap wrote:
>
>> I recently upgraded my Arch Linux system to glibc 2.12 and static
>> binaries compiled with GHC 6.12.3 all fail with the message
>> "mkTextEncoding: invalid argum
On 08/10/2010 03:23, Alexander Dunlap wrote:
I recently upgraded my Arch Linux system to glibc 2.12 and static
binaries compiled with GHC 6.12.3 all fail with the message
"mkTextEncoding: invalid argument (Invalid argument)". This did not
happen with glibc 2.11. Has anyone else had th
Hi all,
I recently upgraded my Arch Linux system to glibc 2.12 and static
binaries compiled with GHC 6.12.3 all fail with the message
"mkTextEncoding: invalid argument (Invalid argument)". This did not
happen with glibc 2.11. Has anyone else had this problem? Does anyone
have any
All,
Conor's problems on OSX with libiconv reminds me of something I've been
thinking about for a little while.
So the problem is that the semantics of static linking does not at all
match what we really want. We can easily accidentally "interpose" a
wrong library in place
I'm writing is
> compiled to a static library and installed with cabal, so students can
> just "ghc --make" or "ghci" their sources. Here comes the problem: I
> want to define main and let students just define labMain as an entry
> point to their program.
&g
On Fri, 2009-04-24 at 13:06 +0200, Krzysztof Skrzętnicki wrote:
> Why not just tell them to import your library and do something like
> > main = withSomeInit labMain
> where "withSomeInit" is the function you provide? This approach is
> present in some other libs that require initialization.
Dear
12:56, Philip K.F. wrote:
> Dear GHCers,
>
> I am trying to write a wrapper library for lab work to give to students.
> My problem is, that the libraries I use require initialization that I
> really want to hide from our students. The wrapper I'm writing is
> compiled to
Dear GHCers,
I am trying to write a wrapper library for lab work to give to students.
My problem is, that the libraries I use require initialization that I
really want to hide from our students. The wrapper I'm writing is
compiled to a static library and installed with cabal, so students can
On Fri, Jan 30, 2009 at 3:28 AM, Simon Marlow wrote:
> Philip Weaver wrote:
>
>> Hello. I think I've seen other people encounter this problem before, but
>> I wasn't able to find the solution, if there is one.
>>
>> I have a very large static list
Philip Weaver wrote:
Hello. I think I've seen other people encounter this problem before,
but I wasn't able to find the solution, if there is one.
I have a very large static list of type [[Int]]. It is 128 lists of 128
integers each. When I try to load the module that defines th
Hello. I think I've seen other people encounter this problem before, but I
wasn't able to find the solution, if there is one.
I have a very large static list of type [[Int]]. It is 128 lists of 128
integers each. When I try to load the module that defines this list, I get
an erro
Peter Gammie wrote:
Hello,
Further on my static linking woes:
debian ~$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.8.2
-debian ~$ cat T.hs
main :: IO ()
main = putStrLn "Hello world"
-debian ~$ ghc -optl-static -static --make T.hs
Linking T ...
/usr/li
Hello,
Further on my static linking woes:
debian ~$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.8.2
-debian ~$ cat T.hs
main :: IO ()
main = putStrLn "Hello world"
-debian ~$ ghc -optl-static -static --make T.hs
Linking T ...
/usr/lib/gcc/i486-linux
jason.dusek:
> I have an awkward programming problem -- I need to take a
> dictionary, parse it, build a bunch of intermediate lists and
> then make maps and tries out of the list. A "programming
> problem" because it's taken me a fair amount of effort to pull
> together the parser and li
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> It's not quite as stupid as it sounds...have another go when
> you see that #2002 is fixed.
Thanks for pointing me to that -- in the meantime, I'd still
rather write C and Haskell than plain C++!
--
_jsn
On Sat, Mar 1, 2008 at 12:24 PM, Jay Scott <[EMAIL PROTECTED]> wrote:
> Jason Dusek [EMAIL PROTECTED]:
> unsafePerformIO should be safe on constants, right? It has worked for
> me, at least.
Unfortunately, reading in the list does not allow me to ship a
single binary. It's not file reading, th
Jason Dusek [EMAIL PROTECTED]:
>Bryan O'Sullivan <[EMAIL PROTECTED]> wrote:
>> The trick I usually use in cases like this is to compile the
>> data as C code and link against it, then access it from
>> Haskell via a Ptr.
>
> For my particular application, I
Bryan O'Sullivan <[EMAIL PROTECTED]> wrote:
> The trick I usually use in cases like this is to compile the
> data as C code and link against it, then access it from
> Haskell via a Ptr.
For my particular application, I really need to ship a single
static binary that has it
jay:
> Don Stewart [EMAIL PROTECTED]:
>
> >jay:
> >> Don Stewart [EMAIL PROTECTED]:
> >> >jay:
> >> >> Don Stewart [EMAIL PROTECTED]:
> >> >> >jay:
> >> >> >> I also have constants that are too large to compile. I am resigned to
> >> >> >> loading them from data files--other solutions seem even wo
Don Stewart [EMAIL PROTECTED]:
>jay:
>> Don Stewart [EMAIL PROTECTED]:
>> >jay:
>> >> Don Stewart [EMAIL PROTECTED]:
>> >> >jay:
>> >> >> I also have constants that are too large to compile. I am resigned to
>> >> >> loading them from data files--other solutions seem even worse.
>> >> ...
>> >> >>
jay:
> Don Stewart [EMAIL PROTECTED]:
> >jay:
> >> Don Stewart [EMAIL PROTECTED]:
> >> >jay:
> >> >> I also have constants that are too large to compile. I am resigned to
> >> >> loading them from data files--other solutions seem even worse.
> >> ...
> >> >> Data.Binary eases the irritation somewha
Don Stewart [EMAIL PROTECTED]:
>jay:
>> Don Stewart [EMAIL PROTECTED]:
>> >jay:
>> >> I also have constants that are too large to compile. I am resigned to
>> >> loading them from data files--other solutions seem even worse.
>> ...
>> >> Data.Binary eases the irritation somewhat.
>> >
>> >Did you t
Don Stewart [EMAIL PROTECTED]:
>jay:
>> Don Stewart [EMAIL PROTECTED]:
>> >jay:
>> >> I also have constants that are too large to compile. I am resigned to
>> >> loading them from data files--other solutions seem even worse.
>> ...
>> >> Data.Binary eases the irritation somewhat.
>> >
>> >Did you
| On another note, I am extremely curious about the difference
| between statically compiling a list and building it at
| runtime. I find it hard to wrap my head around the fact that I
| can build the list at runtime in a short time, but can not
| compile it without eating all of my machi
Is it _possible_ to use Template Haskell to take the name of the external binary
file and produce such a bytestring literal?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell
jay:
> Don Stewart [EMAIL PROTECTED]:
> >jay:
> >> I also have constants that are too large to compile. I am resigned to
> >> loading them from data files--other solutions seem even worse.
> ...
> >> Data.Binary eases the irritation somewhat.
> >
> >Did you try bytestring literals (and maybe parsin
Jay Scott wrote:
> That didn't occur to me, since neither of my large constants includes
> strings
The trick I usually use in cases like this is to compile the data as C
code and link against it, then access it from Haskell via a Ptr.
http://www.haskell.org/mailman/listinfo/glasgow-h
Don Stewart [EMAIL PROTECTED]:
>jay:
>> I also have constants that are too large to compile. I am resigned to
>> loading them from data files--other solutions seem even worse.
...
>> Data.Binary eases the irritation somewhat.
>
>Did you try bytestring literals (and maybe parsing them in-memory with
jay:
> Jason Dusek [EMAIL PROTECTED]:
> > I have an awkward programming problem -- I need to take a
> > dictionary, parse it, build a bunch of intermediate lists and
> > then make maps and tries out of the list. A "programming
> > problem" because it's taken me a fair amount of effort to pull
>
Jason Dusek [EMAIL PROTECTED]:
> I have an awkward programming problem -- I need to take a
> dictionary, parse it, build a bunch of intermediate lists and
> then make maps and tries out of the list. A "programming
> problem" because it's taken me a fair amount of effort to pull
> together the
jason.dusek:
> Don Stewart <[EMAIL PROTECTED]> wrote:
> > You can build large constant bytestrings, fwiw. They turn into
> > an Addr#, and GHC will leave them alone.
>
> Well, for my particular problem -- I guess I could align all
> the elements of the lists, and then build the trie and maps
>
Don Stewart <[EMAIL PROTECTED]> wrote:
> You can build large constant bytestrings, fwiw. They turn into
> an Addr#, and GHC will leave them alone.
Well, for my particular problem -- I guess I could align all
the elements of the lists, and then build the trie and maps
from the ByteStrings at
jason.dusek:
> I have an awkward programming problem -- I need to take a
> dictionary, parse it, build a bunch of intermediate lists and
> then make maps and tries out of the list. A "programming
> problem" because it's taken me a fair amount of effort to pull
> together the parser and li
I have an awkward programming problem -- I need to take a
dictionary, parse it, build a bunch of intermediate lists and
then make maps and tries out of the list. A "programming
problem" because it's taken me a fair amount of effort to pull
together the parser and list generator -- and "aw
ect of any serious size and complexity, the use
of static or dynamic linking is often architechted in and
cannot be changed. So LGPL is really bad for a general
purpose compiler like GHC. We've got to make GMP
optional, or get rid of it.
Well, I think you misunderstood what I was trying to sa
Hello,
On Thursday 17 January 2008 05:24, Manuel M T Chakravarty wrote:
> Thorkil Naur:
> > Hello,
> >
> > On Tuesday 08 January 2008 15:07, Christian Maeder wrote:
> >> Hi,
> >>
> >> I've succeeded in building a binary distribution
Hello Yitzchak,
Thursday, January 17, 2008, 7:10:54 PM, you wrote:
> Wow, I didn't realize that. Now I understand Bulat. In a
> project of any serious size and complexity, the use
> of static or dynamic linking is often architechted in and
> cannot be changed. So LGPL is really
Hello Isaac,
Thursday, January 17, 2008, 8:05:56 PM, you wrote:
> (b) is a sufficient condition, but not necessary; there are other ways
> to satisfy the license. It's also possible to just distribute, for
> example, the .o file(s) and a way to link them with a GMP to get the
> final result; th
Isaac Dupree wrote:
> It's also possible to just distribute, for
> example, the .o file(s) and a way to link them with a GMP to get the
> final result; this doesn't even reveal your source-code any more than
> your program being dynamically linked, at least if you do it right -- right?
It doesn't
Hello Manuel,
Thursday, January 17, 2008, 7:49:00 AM, you wrote:
>> for me, GMP is much more problematic issue. strictly speaking, we
>> can't say that GHC is BSD-licensed because it includes LGPL-licensed
>> code (and that much worse, it includes this code in run-time libs)
> use of GMP in the c
project of any serious size and complexity, the use
of static or dynamic linking is often architechted in and
cannot be changed.
(b) is a sufficient condition, but not necessary; there are other ways
to satisfy the license. It's also possible to just distribute, for
example, the .o file(
Now I understand Bulat. In a
project of any serious size and complexity, the use
of static or dynamic linking is often architechted in and
cannot be changed. So LGPL is really bad for a general
purpose compiler like GHC. We've got to make GMP
optional, or get rid of it.
-Yitz
_
Bulat Ziganshin:
for me, GMP is much more problematic issue. strictly speaking, we
can't say that GHC is BSD-licensed because it includes LGPL-licensed
code (and that much worse, it includes this code in run-time libs)
Of course, GHC is BSD3 licensed. It includes the GMP code as part of
its
Thorkil Naur:
Hello,
On Tuesday 08 January 2008 15:07, Christian Maeder wrote:
Hi,
I've succeeded in building a binary distribution that uses static
libraries for gmp and readline. libreadline.a, libncurses.a and
libgmp.a
with corresponding header files are included. (For license i
Bulat Ziganshin wrote:
>>> in short, that means that software compiled with this compiler AND
>>> distributed to general audience, should have GPL-compatible license
>>> (i.e. GPL or BSD-like)
>>> (as far as i understand GPL/LGPL terms)
>> Any software compiled with this compiler, or only
>> softw
Hello Yitzchak,
Thursday, January 10, 2008, 1:06:12 PM, you wrote:
>>> "Readline is free software, distributed under the terms of the GNU General
>>> Public License, version 2.
>> in short, that means that software compiled with this compiler AND
>> distributed to general audience, should have G
Thorkil Naur wrote:
>> "Readline is free software, distributed under the terms of the GNU General
>> Public License, version 2.
Bulat Ziganshin wrote:
> in short, that means that software compiled with this compiler AND
> distributed to general audience, should have GPL-compatible license
> (i.e.
Hello Thorkil,
Thursday, January 10, 2008, 11:24:16 AM, you wrote:
>> I've succeeded in building a binary distribution that uses static
>> libraries for gmp and readline.
> "GMP is distributed under the GNU LGPL. This license makes the library free to
> "Readl
Hello,
On Tuesday 08 January 2008 15:07, Christian Maeder wrote:
> Hi,
>
> I've succeeded in building a binary distribution that uses static
> libraries for gmp and readline. libreadline.a, libncurses.a and libgmp.a
> with corresponding header files are included. (Fo
Christian Maeder wrote:
>> I've succeeded in building a binary distribution that uses static
>> libraries for gmp and readline. libreadline.a, libncurses.a and libgmp.a
>> with corresponding header files are included. (For license issues ask
>> someone else.) L
Christian Maeder wrote:
> Hi,
>
> I've succeeded in building a binary distribution that uses static
> libraries for gmp and readline. libreadline.a, libncurses.a and libgmp.a
> with corresponding header files are included. (For license issues ask
> someone else.) Linking
Hi,
I've succeeded in building a binary distribution that uses static
libraries for gmp and readline. libreadline.a, libncurses.a and libgmp.a
with corresponding header files are included. (For license issues ask
someone else.) Linking is done using the flag -search_paths_first.
Framewor
Dimitry Golubovsky wrote:
The Paragraph 4.10.7 of the GHC users guide contains this:
-static
Tell the linker to avoid shared Haskell libraries, if possible. This
is the default.
-dynamic
Tell the linker to use shared Haskell libraries, if available (this
option is only supported on Mac OS X at
The Paragraph 4.10.7 of the GHC users guide contains this:
-static
Tell the linker to avoid shared Haskell libraries, if possible. This
is the default.
-dynamic
Tell the linker to use shared Haskell libraries, if available (this
option is only supported on Mac OS X at the moment, and also note
On Sat, Mar 26, 2005 at 03:11:43PM +0100, Patrick Scheibe wrote:
> Is it possible to tell ghc to take all stuff out of the .so libs and compile
> my source to a "all-including" executable?
> I know that ghc just calls the linker which is doing this part. The --static
> fl
possible to tell ghc to take all stuff out of the .so libs and compile
my source to a "all-including" executable?
I know that ghc just calls the linker which is doing this part. The --static
flag for the linker just says: "take the static library if possible for
linking..."
wolfgang.thaller:
>
> On 09.03.2004, at 15:53, Ian Lynagh wrote:
>
> >On Tue, Mar 09, 2004 at 01:04:59AM +0100, Wolfgang Thaller wrote:
> >>
> >>So I assume this is on powerpc-linux?
> >
> >Yup, sorry (and the others are all Linux too).
>
> A
On 09.03.2004, at 15:53, Ian Lynagh wrote:
On Tue, Mar 09, 2004 at 01:04:59AM +0100, Wolfgang Thaller wrote:
So I assume this is on powerpc-linux?
Yup, sorry (and the others are all Linux too).
Ah yes, that -static flag was lurking there from the old AIX port. It's
definitely OK to remo
On Tue, Mar 09, 2004 at 01:04:59AM +0100, Wolfgang Thaller wrote:
>
> So I assume this is on powerpc-linux?
Yup, sorry (and the others are all Linux too).
Thanks
Ian
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mail
What platform? Does everything work if you remove the -static?
alpha, powerpc and hppa so far. I expect the same will happen for mips
and mipsel.
If, on powerpc, I run the final link command without -static
(that's the
only place it should make a difference, right?) then it links without
war
On Mon, Mar 08, 2004 at 03:25:06PM +, Ian Lynagh wrote:
> On Mon, Mar 08, 2004 at 11:07:07AM -, Simon Marlow wrote:
> >
> > What platform? Does everything work if you remove the -static?
>
> alpha, powerpc and hppa so far. I expect the same will happen for mips
gt; > : warning: Using 'getgrgid_r' in statically linked
> > > applications requires at runtime the shared libraries from
> > > the glibc version used for linking
> > >
> > > which I assume would lead to too strict dependencies on
> glibc being
> > >
statically linked
> > applications requires at runtime the shared libraries from
> > the glibc version used for linking
> >
> > which I assume would lead to too strict dependencies on glibc being
> > necessary.
>
> What platform? Does everything work if yo
> In ghc/compiler/main/DriverFlags.hs machdepCCOpts includes a "-static"
> flag for some arches. Is this really necessary? I can't see
> any comments
> as to why, nor any real answers from a quick google.
I can't remember why either.
> It causes this w
Hi,
In ghc/compiler/main/DriverFlags.hs machdepCCOpts includes a "-static"
flag for some arches. Is this really necessary? I can't see any comments
as to why, nor any real answers from a quick google.
It causes this when compiling darcs on these arches:
/usr/lib/ghc-6.2/lib
> How do I go about linking to a static library when using --make?
>
> If i do
>
> ghc --make Module libmodulelib.a
>
> then ghc syas:
>
> chasing modules from Module,libmodulelib.a and complains
> about not being
> able to find the _module_ modulelib.a. Like
tor 2002-10-10 klockan 14.02 skrev Martin Norbäck:
> How do I go about linking to a static library when using --make?
>
> If i do
>
> ghc --make Module libmodulelib.a
>
> then ghc syas:
>
> chasing modules from Module,libmodulelib.a and complains about not being
How do I go about linking to a static library when using --make?
If i do
ghc --make Module libmodulelib.a
then ghc syas:
chasing modules from Module,libmodulelib.a and complains about not being
able to find the _module_ modulelib.a. Likewise on windows, if I do
ghc --make Module
In local.glasgow-haskell-users, you wrote:
>> I think it would be a good idea to add -optl-static to the flags
>> described in
>> http://www.haskell.org/ghc/docs/latest/html/users_guide/option
>> s-phases.html#OPTIONS-LINKER
>> perhaps in the vincinity of -st
1 - 100 of 109 matches
Mail list logo
