>> so you could add info about required packages in the object file,
>
>Yes, both of these are good ideas. However, they both require noodling
>in object files of course, which is non-portable. Or perhaps creative
>use of 'nm' or 'objdump' would do.
>
>In any case, I think we already arrived at a
On 13 September 2004 19:40, Claus Reinke wrote:
>> Just to expand on this a little: it's not clear that we could do this
>> even if we wanted to. Given an arbitrary .o file, we can't tell (a)
>> if it is a compiled Haskell module and (b) if so, where its .hi file
>> can be found. We can make gue
>Just to expand on this a little: it's not clear that we could do this
>even if we wanted to. Given an arbitrary .o file, we can't tell (a) if
>it is a compiled Haskell module and (b) if so, where its .hi file can be
>found. We can make guesses, but there isn't a general solution.
the only .o fi
On Wed, Sep 08, 2004 at 10:35:35AM +0100, Simon Marlow wrote:
> Following up to my own message:
>
> On 08 September 2004 10:26, Simon Marlow wrote:
[..]
> > Not to mention incompatible C libraries: suppose I have two packages
> > implementing Haskll layers over gtk 1.2 and 2.0 - I can't try to lin
> > But if I have two layers over gtk 1.2 and 2.0 and both use the
> > hierarchical module system and are therefore marked as "auto" you
> > would have the same problem of linking in two versions of gtk which
> > doesn't work. Did I miss something?
The "auto" flag does *not* mean "uses hierarchica
On 08 September 2004 12:50, Axel Simon wrote:
> On Wed, Sep 08, 2004 at 10:35:35AM +0100, Simon Marlow wrote:
>> Following up to my own message:
>>
>> On 08 September 2004 10:26, Simon Marlow wrote:
> [..]
>>> Not to mention incompatible C libraries: suppose I have two packages
>>> implementing H
Axel Simon wrote (snipped):
But if I have two layers over gtk 1.2 and 2.0 and both use the
hierarchical module system and are therefore marked as "auto" you would
have the same problem of linking in two versions of gtk which doesn't
work. Did I miss something?
I presume that Simon meant that onl
Following up to my own message:
On 08 September 2004 10:26, Simon Marlow wrote:
> It is possible to have incompatible packages - i.e. packages that
> export identical symbols and so can't both be present on the link
> line. The recent package proposal allows packages to overlap, so in
> order to
On 07 September 2004 17:45, Alastair Reid wrote:
> SimonM:
>>> So you're proposing that -package options should *always* be
>>> required?
>
> Why is it necessary to provide -package options at all?
>
> ghc-pkg knows about all the packages in your system so it could just
> implicitly add -packag
Alastair Reid wrote (snipped):
Why is it necessary to provide -package options at all?
ghc-pkg knows about all the packages in your system so it could just
implicitly add -package $x for every package when compiling or linking.
My current need at least is to disable the lang, text, data packages a
On Tuesday 07 September 2004 17:52, Simon Peyton-Jones wrote:
> That's exactly what I think. Currently we require the -package flags
> when linking solely for efficiency reasons: linking would be slow if ld
> was given every lib.a file installed for that compiler. But perhaps
> that should be the
| Why is it necessary to provide -package options at all?
|
| ghc-pkg knows about all the packages in your system so it could just
| implicitly add -package $x for every package when compiling or
linking.
That's exactly what I think. Currently we require the -package flags
when linking solely f
SimonM:
> > So you're proposing that -package options should *always* be required?
Why is it necessary to provide -package options at all?
ghc-pkg knows about all the packages in your system so it could just
implicitly add -package $x for every package when compiling or linking.
When would you
On 07 September 2004 16:45, George Russell wrote:
> The problem is that if package A includes an import of
> Text.ParserCombinators.Parsec and package B includes a module
> which uses Template Haskell code that requires package B,
> you are liable to get things falling over at compile-time.
> This
Simon Marlow wrote (snipped):
Could you elaborate on the template haskell problem you mentioned? I
don't think template haskell is affected by this (i.e. it's still just
batch linking that requires the -package options, template haskell
should still work just fine without them).
The problem is tha
On 07 September 2004 12:24, George Russell wrote:
> Simon Peyton-Jones wrote:
>> It's documented behaviour.
>>
>> * import Text.ParserCombinators.Parsec will work without any -package
>> flags, if any installed package has a module
>> Text.ParserCombinators.Parsec. It's very tiresome adding -pac
Simon Peyton-Jones wrote:
It's documented behaviour.
* import Text.ParserCombinators.Parsec will work without any -package
flags, if any installed package has a module
Text.ParserCombinators.Parsec. It's very tiresome adding -package flags
all the time.
* The link step needs -package flags, becaus
On 07 September 2004 02:21, Dean Herington wrote:
> At 1:52 PM +0100 9/6/04, Simon Marlow wrote:
>> On 06 September 2004 13:43, Simon Peyton-Jones wrote:
>>
>>> * The link step needs -package flags, because it only gets .o
>>> files, and we didn't want it to start hunting through .hi files
>>>
At 1:52 PM +0100 9/6/04, Simon Marlow wrote:
On 06 September 2004 13:43, Simon Peyton-Jones wrote:
* The link step needs -package flags, because it only gets .o files,
and we didn't want it to start hunting through .hi files (though that
would be possible)
Just to expand on this a little: it's n
On 06 September 2004 13:43, Simon Peyton-Jones wrote:
> * The link step needs -package flags, because it only gets .o files,
> and we didn't want it to start hunting through .hi files (though that
> would be possible)
Just to expand on this a little: it's not clear that we could do this
even if w
Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of George Russell
| Sent: 06 September 2004 11:35
| To: Ross Paterson
| Cc: [EMAIL PROTECTED]
| Subject: Re: Text.ParserCombinators.Parsec requires -package text.
|
| Ross Paterson wrote
Ross Paterson wrote:
On Mon, Sep 06, 2004 at 12:10:09PM +0200, George Russell wrote:
With
ghc ParsecTest.hs -o pt
you get a link-time failure, because it looks as if the base package
Text.ParserCombinators.Parsec depends somehow on the package "text".
Try -package parsec
OK, I have. But if pars
On Mon, Sep 06, 2004 at 12:10:09PM +0200, George Russell wrote:
> With
>ghc ParsecTest.hs -o pt
> you get a link-time failure, because it looks as if the base package
> Text.ParserCombinators.Parsec depends somehow on the package "text".
Try -package parsec
With
ghc ParsecTest.hs -o pt
you get a link-time failure, because it looks as if the base package
Text.ParserCombinators.Parsec depends somehow on the package "text".
module Main where
import Text.ParserCombinators.Parsec
ch = char 'C'
main =
do
seq ch (return ())___
24 matches
Mail list logo
