Porting to DragonFly BSD

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Porting to DragonFly BSD

Colin Adams-3
When GHC 6.12.1 is released, I'm going to have a go at porting it to
DragonFly BSD (32-bit incarnation). Is the porting page on the
wikiup-to-date?

--
Colin Adams
Preston,
Lancashire,
ENGLAND
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

Simon Marlow-7
On 04/11/2009 15:08, Colin Adams wrote:
> When GHC 6.12.1 is released, I'm going to have a go at porting it to
> DragonFly BSD (32-bit incarnation). Is the porting page on the
> wikiup-to-date?

There are apparently some difficulties with porting right now:

http://hackage.haskell.org/trac/ghc/ticket/3472

Depending on how similar the host/target archtectures are, it might be
possible to follow the instructions to get a working port.

We need to have another run at doing a port and iron out the bugs in the
procedure.

Cheers,
        Simon
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

Matthias Kilian
On Fri, Nov 06, 2009 at 08:56:00AM +0000, Simon Marlow wrote:
> On 04/11/2009 15:08, Colin Adams wrote:
> >When GHC 6.12.1 is released, I'm going to have a go at porting it to
> >DragonFly BSD (32-bit incarnation). Is the porting page on the
> >wikiup-to-date?
>
> There are apparently some difficulties with porting right now:
>
> http://hackage.haskell.org/trac/ghc/ticket/3472

Unfortunately I didn't have much time after the OpenBSD p2k9 in
Budapesst (where I got a little bit further with the bootstrapping),
but I remember that I got parts of stage 1 built but then something
in utils/* didn't compile.

I hope to have a look this weekend (and to find the patches I wrote
in Budapest). There are probably just some more pattern rules missing
for the .hc file bootstrapping.

> Depending on how similar the host/target archtectures are, it might be
> possible to follow the instructions to get a working port.

Once the make rules are complete, the Linker may be tricky (it
already contains #ifdef'd sections specific to FreeBSD and OpenBSD),
but I don't expect other parts of GHC to need tweaking.

> We need to have another run at doing a port and iron out the bugs in the
> procedure.

At least I tried to correct some of the hints on the porting wiki
page, but it's obviously still incomplete.

Ciao,
        Kili
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

G.Isenmann
In reply to this post by Colin Adams-3
On Wed, Nov 04, 2009 at 03:08:27PM +0000, Colin Adams wrote:
> When GHC 6.12.1 is released, I'm going to have a go at porting it to
> DragonFly BSD (32-bit incarnation). Is the porting page on the
> wikiup-to-date?

Maybe you could start with something like:

$ curl -o ghc-6.10.4-3.tar.bz2 \
;   http://www.goetz-isenmann.de/dfly/ghc-6.10.4-3.tar.bz2
$ curl -o cabal http://www.goetz-isenmann.de/dfly/cabal
$ tar xzf ghc-6.10.4-3.tar.bz2 -C /var/tmp/isenmann
$ PATH=/var/tmp/isenmann/ghc-6.10.4-3/bin:$PATH
$ ./cabal update
$ ./cabal install --user cabal-install

I have just recompiled this ghc with itself using the attached
patches and --prefix=/var/tmp/isenmann on dragonfly 2.4.1 (32bit).

The patches are only a stupid "do the same for dragonfly as for
freebsd" with two exceptions AFAIR: (a) use -pthread not -lthr, and
(b) this -D_POSIX_VERSION=199309 in rts/Makefile, that's most probably
the wrong way to fix a (can't remember the details) build problem.

Until now I had no time and energie to dig deeper into the problem
[1], that looks to me, like rts/Linker cannot load any object file
that references errno.

My guess is, that for dragonflys "extern __thread int errno;" we do
not only need to add a new case in rts/Linker.c but also need to
generate different code for this thread local storage access.

Goetz


[1] $ ghci
GHCi, version 6.10.4: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
ghc: /var/tmp/isenmann/ghc-6.10.4-3/lib/ghc-6.10.4/base-4.1.0.0/HSbase-4.1.0.0.o: unhandled ELF relocation(Rel) type 15

Loading package base ... linking ... ghc: unable to load package `base'

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ghc-6.10.4-dfly.diff (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

Colin Paul Adams
>>>>> "Goetz" == Goetz Isenmann <[hidden email]> writes:

    Goetz> Maybe you could start with something like:

    Goetz> $ curl -o ghc-6.10.4-3.tar.bz2 \ ;
    Goetz> http://www.goetz-isenmann.de/dfly/ghc-6.10.4-3.tar.bz2 $
    Goetz> curl -o cabal http://www.goetz-isenmann.de/dfly/cabal $ tar
    Goetz> xzf ghc-6.10.4-3.tar.bz2 -C /var/tmp/isenmann $
    Goetz> PATH=/var/tmp/isenmann/ghc-6.10.4-3/bin:$PATH $ ./cabal
    Goetz> update $ ./cabal install --user cabal-install

This looks confusing to me - you name the file .bz2 yet you are saying
use tar xzf to extract it (as if it were gzipped0. Whatever, I can't
decompress it.
--
Colin Adams
Preston Lancashire
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

Simon Marlow-7
In reply to this post by G.Isenmann
On 06/11/2009 23:25, Goetz Isenmann wrote:

> On Wed, Nov 04, 2009 at 03:08:27PM +0000, Colin Adams wrote:
>> When GHC 6.12.1 is released, I'm going to have a go at porting it to
>> DragonFly BSD (32-bit incarnation). Is the porting page on the
>> wikiup-to-date?
>
> Maybe you could start with something like:
>
> $ curl -o ghc-6.10.4-3.tar.bz2 \
> ;   http://www.goetz-isenmann.de/dfly/ghc-6.10.4-3.tar.bz2
> $ curl -o cabal http://www.goetz-isenmann.de/dfly/cabal
> $ tar xzf ghc-6.10.4-3.tar.bz2 -C /var/tmp/isenmann
> $ PATH=/var/tmp/isenmann/ghc-6.10.4-3/bin:$PATH
> $ ./cabal update
> $ ./cabal install --user cabal-install
>
> I have just recompiled this ghc with itself using the attached
> patches and --prefix=/var/tmp/isenmann on dragonfly 2.4.1 (32bit).
>
> The patches are only a stupid "do the same for dragonfly as for
> freebsd" with two exceptions AFAIR: (a) use -pthread not -lthr, and
> (b) this -D_POSIX_VERSION=199309 in rts/Makefile, that's most probably
> the wrong way to fix a (can't remember the details) build problem.
>
> Until now I had no time and energie to dig deeper into the problem
> [1], that looks to me, like rts/Linker cannot load any object file
> that references errno.
>
> My guess is, that for dragonflys "extern __thread int errno;" we do
> not only need to add a new case in rts/Linker.c but also need to
> generate different code for this thread local storage access.

Great work.  I've added Dragonfly BSD to the list of Tier 2 platforms:
http://hackage.haskell.org/trac/ghc/wiki/Platforms

Would you be willing to be the maintainer for GHC on Dragonfly?

We should get these patches into GHC.  Most of them look
straightforward, but I'm slightly suspicious of this:

-STANDARD_OPTS += -DCOMPILING_RTS
+STANDARD_OPTS += -DCOMPILING_RTS -D_POSIX_VERSION=199309

why was that necessary?

Cheers,
        Simon
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

G.Isenmann
On Mon, Nov 09, 2009 at 10:44:47AM +0000, Simon Marlow wrote:
> We should get these patches into GHC.  Most of them look
> straightforward, but I'm slightly suspicious of this:
>
> -STANDARD_OPTS += -DCOMPILING_RTS
> +STANDARD_OPTS += -DCOMPILING_RTS -D_POSIX_VERSION=199309
>
> why was that necessary?

Good that you ask. Can't remember why it was necessary back in april
to build ghc-6.10.2 on dragonfly-2.2.1. Cannot reproduce the problem
today with ghc-6.10.4 on dragonfly-2.4.1.

I am glad, that we do not need this define any more. I think it was a
ugly workaround at best.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

Tyson Whitehead
On November 9, 2009 12:39:25 Goetz Isenmann wrote:

> On Mon, Nov 09, 2009 at 10:44:47AM +0000, Simon Marlow wrote:
> > We should get these patches into GHC.  Most of them look
> > straightforward, but I'm slightly suspicious of this:
> >
> > -STANDARD_OPTS += -DCOMPILING_RTS
> > +STANDARD_OPTS += -DCOMPILING_RTS -D_POSIX_VERSION=199309
> >
> > why was that necessary?
>
> Good that you ask. Can't remember why it was necessary back in april
> to build ghc-6.10.2 on dragonfly-2.2.1. Cannot reproduce the problem
> today with ghc-6.10.4 on dragonfly-2.4.1.
>
> I am glad, that we do not need this define any more. I think it was a
> ugly workaround at best.
I'm not sure about dragonfly, but there are a bunch of similar options for
glibc under Linux.  For example, "man feature_test_macros" says you need to
define _POSIX_C_SOURCE to 199309 or greater to use POSIX.1b functionality.

Cheers!  -Tyson

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

Colin Paul Adams
In reply to this post by G.Isenmann
>>>>> "Goetz" == Goetz Isenmann <[hidden email]> writes:


    Goetz> Until now I had no time and energie to dig deeper into the
    Goetz> problem [1], that looks to me, like rts/Linker cannot load
    Goetz> any object file that references errno.

    Goetz> My guess is, that for dragonflys "extern __thread int
    Goetz> errno;" we do not only need to add a new case in
    Goetz> rts/Linker.c but also need to generate different code for
    Goetz> this thread local storage access.


    Goetz> [1] $ ghci GHCi, version 6.10.4:
    Goetz> http://www.haskell.org/ghc/ :? for help Loading package
    Goetz> ghc-prim ... linking ... done.  Loading package integer
    Goetz> ... linking ... done.  ghc:
    Goetz> /var/tmp/isenmann/ghc-6.10.4-3/lib/ghc-6.10.4/base-4.1.0.0/HSbase-4.1.0.0.o:
    Goetz> unhandled ELF relocation(Rel) type 15

    Goetz> Loading package base ... linking ... ghc: unable to load
    Goetz> package `base'

After some googling, and learning very little, I speclated that simply
adding a third line for R_386_TLS_IE with the same action as the first
line - just storing value, might work:

case R_386_TLS_IE: *pP = value; break;

This seems to work up to a point. That is I get no crashes in ghci.

I do appear to have some line-feed problems. So if I type:

Prelude> let x = 10

It appears to do nothing, but that is not the case - I can then
overtype with :t x and ghci responds with:

x :: Integerxx = 10
Prelude>

So maybe this is a readline/haskelline issue?

I then tried a cabal install of my website application. This fails,
but I think it is because I need to apply various patches to haskelldb
modules that are not yet in hackage.
--
Colin Adams
Preston Lancashire
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

G.Isenmann
On Sat, Nov 14, 2009 at 04:16:58PM +0000, Colin Paul Adams wrote:
>     Goetz> Until now I had no time and energie to dig deeper into the
>     Goetz> problem [1], that looks to me, like rts/Linker cannot load
>     Goetz> any object file that references errno.

Seems to be worse when I try to build snapshot ghc-6.13.20091111. I
get a relocation error much earlier during the stage2 build.

>     Goetz> My guess is, that for dragonflys "extern __thread int
>     Goetz> errno;" we do not only need to add a new case in
>     Goetz> rts/Linker.c but also need to generate different code for
>     Goetz> this thread local storage access.

I am still not sure, but the generated code might be ok

001e5565 <__hscore_get_errno>:
  1e5565:       55                      push   %ebp
  1e5566:       89 e5                   mov    %esp,%ebp
  1e5568:       65 a1 00 00 00 00       mov    %gs:0x0,%eax
  1e556e:       8b 15 00 00 00 00       mov    0x0,%edx
  1e5574:       8b 04 10                mov    (%eax,%edx,1),%eax
  1e5577:       c9                      leave  
  1e5578:       c3                      ret    

The corresponding relocation info is

001e5570 R_386_TLS_IE      errno

>     Goetz> [1] $ ghci GHCi, version 6.10.4:
>     Goetz> http://www.haskell.org/ghc/ :? for help Loading package
>     Goetz> ghc-prim ... linking ... done.  Loading package integer
>     Goetz> ... linking ... done.  ghc:
>     Goetz> /var/tmp/isenmann/ghc-6.10.4-3/lib/ghc-6.10.4/base-4.1.0.0/HSbase-4.1.0.0.o:
>     Goetz> unhandled ELF relocation(Rel) type 15
>
>     Goetz> Loading package base ... linking ... ghc: unable to load
>     Goetz> package `base'
>
> After some googling, and learning very little, I speclated that simply
> adding a third line for R_386_TLS_IE with the same action as the first
> line - just storing value, might work:
>
> case R_386_TLS_IE: *pP = value; break;
>
> This seems to work up to a point. That is I get no crashes in ghci.
I have also tried this, but I do not believe, that something that
simple will work. At least it should pass this test: When you try to
open a file that does not exist

Prelude> System.IO.openFile "xxx" System.IO.ReadMode

you should get

*** Exception: xxx: openFile: does not exist (No such file or directory)

and not (Unknown error: ...).


My current strategie is, to avoid the problem in a first step.

With the attached errno_ptr.{h,c} I create a shared library, that
encapsulates the errno access, install the header file as
/usr/pkg/include/errno_ptr.h and the shared lib as
/usr/pkg/lib/liberrno_ptr.so

Building ghc-6.10.4 with the attached patch (only a quick hack, to
check the idea) I get a result, that looks much better.

@Colin: Maybe you can test and use this hack.

@Simon: I am not sure, in which direction I should look for solving
this problem:

 1. Avoid the tls problem
    a) Try to convince the dragonfly people, that it might be useful,
       to have something like the errno access wrapper in libc.
    b) If (1a) fails, try to create a patch for netbsd pkgsrc and/or
       ghc, so that an access wrapper will be created and installed
       as part of a ghc installation on dragonfly.
 2. Fix the problem
    a) Try to add the necessary logic into the ghc runtime.
    b) Try to use the platforms loader.
    Have no clue, if and how (2a) or (2b) are possible, where to get
    some help or at least the necessary information.

Goetz

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

errno_ptr.h (23 bytes) Download Attachment
errno_ptr.c (95 bytes) Download Attachment
00-build (70 bytes) Download Attachment
liberrno_ptr.so (5K) Download Attachment
ghc-6.10.4-dfly-5.diff (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

Colin Paul Adams
>>>>> "Goetz" == Goetz Isenmann <[hidden email]> writes:

    Goetz> @Colin: Maybe you can test and use this hack.

I won't have any time for the next three weeks (work then holiday).
--
Colin Adams
Preston Lancashire
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

Brandon S Allbery KF8NH
In reply to this post by Colin Paul Adams
On Nov 14, 2009, at 11:16 , Colin Paul Adams wrote:

> This seems to work up to a point. That is I get no crashes in ghci.
>
> I do appear to have some line-feed problems. So if I type:
>
> Prelude> let x = 10
>
> It appears to do nothing, but that is not the case - I can then
> overtype with :t x and ghci responds with:
>
> x :: Integerxx = 10
> Prelude>
>
> So maybe this is a readline/haskelline issue?
Known issue, yes, also seen on OSX.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

PGP.sig (202 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

Simon Marlow-7
In reply to this post by G.Isenmann
On 15/11/2009 12:42, Goetz Isenmann wrote:

> @Simon: I am not sure, in which direction I should look for solving
> this problem:
>
>   1. Avoid the tls problem
>      a) Try to convince the dragonfly people, that it might be useful,
>         to have something like the errno access wrapper in libc.
>      b) If (1a) fails, try to create a patch for netbsd pkgsrc and/or
>         ghc, so that an access wrapper will be created and installed
>         as part of a ghc installation on dragonfly.

You can write an access wrapper for errno, compile it into a .so shared
object, and have GHCi load the .so.

>   2. Fix the problem
>      a) Try to add the necessary logic into the ghc runtime.

Have a look at what the system's linker does to resolve this reference:
compile a C program, load it up into gdb, and disassemble the code.

>      b) Try to use the platforms loader.

See above.  Also when we have a dynamically linked GHCi this problem
will partly go away for you
(http://hackage.haskell.org/trac/ghc/ticket/3658).

Cheers,
        Simon
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

Tyson Whitehead
In reply to this post by G.Isenmann
On November 15, 2009 07:42:46 Goetz Isenmann wrote:

> I am still not sure, but the generated code might be ok
>
> 001e5565 <__hscore_get_errno>:
>   1e5565:       55                      push   %ebp
>   1e5566:       89 e5                   mov    %esp,%ebp
>   1e5568:       65 a1 00 00 00 00       mov    %gs:0x0,%eax
>   1e556e:       8b 15 00 00 00 00       mov    0x0,%edx
>   1e5574:       8b 04 10                mov    (%eax,%edx,1),%eax
>   1e5577:       c9                      leave
>   1e5578:       c3                      ret
>
> The corresponding relocation info is
>
> 001e5570 R_386_TLS_IE      errno
Not sure about DragonFly, but under Linux that would be the TLS initial-
executable model .  It is assuming that the TLS memory has already been
allocated and is at the location pointed to by the word at %gs:0x0.

The default when working with position-independent code is the dynamic model.  
It has to go through ___tls_get_addr in order to give the dynamic loader a
chance to allocate the thread local storage memory if this is the first access

The GNU variant of the code for this model is

0x00 leal x@tlsgd(,%ebx,1),%eax
0x07 call ___tls_get_addr@plt

It returns the address in eax.  The two relocation are R_386_TLS_GD to load
eax to point to the GOT entry for the desired symbol and R_386_PLT32 for the
call ___tls_get_addr.

For more details on the four different modes (each one is a successive
optimization of the general dynamic model for cases where the symbol is in the
some shared object and/or the TLS memory is know to be allocated)

http://people.redhat.com/drepper/tls.pdf

(pages 19, 27, 36, and 44 give the code for the fully generic and each
combination of the optimizations respectively).

Under gcc you can specify the model via the "-ftls-model=<model>" option or on
a per-identifier basis with __attribute__((tls_model("<model>"))).  Besides
changing what code is emitted, it sets the STATIC_TLS flag in the dynamic
section to tell force allocation at thread creation if required.

Cheers!  -Tyson

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

Tyson Whitehead
In reply to this post by G.Isenmann
On November 15, 2009 07:42:46 Goetz Isenmann wrote:

> 001e5565 <__hscore_get_errno>:
>   1e5565:       55                      push   %ebp
>   1e5566:       89 e5                   mov    %esp,%ebp
>   1e5568:       65 a1 00 00 00 00       mov    %gs:0x0,%eax
>   1e556e:       8b 15 00 00 00 00       mov    0x0,%edx
>   1e5574:       8b 04 10                mov    (%eax,%edx,1),%eax
>   1e5577:       c9                      leave
>   1e5578:       c3                      ret
>
> The corresponding relocation info is
>
> 001e5570 R_386_TLS_IE      errno
>
> > After some googling, and learning very little, I speclated that simply
> > adding a third line for R_386_TLS_IE with the same action as the first
> > line - just storing value, might work:
> >
> > case R_386_TLS_IE: *pP = value; break;
> >
> > This seems to work up to a point. That is I get no crashes in ghci.
According to "ELF Handling For Thread-Local Storage", R_386_TLS_IE "resolves
to the absolute address of the GOT [global offset table] slot" that is assigned
to the TLS (thread local storage) symbol.

http://people.redhat.com/drepper/tls.pdf   (middle of page 37)

The GOT slot is assigned a R_386_TLS_TPOFF relocation for the symbol.

So, what you are suppose to get is:

1- While linking, the linker resolves the R_386_TLS_IE relocation by updating
the instruction with the absolute address of the corresponding GOT slot.

2- While loading, the dynamic linker resolves the R_386_TLS_TPOFF relocation
by updating the GOT slot to contain the offset of the symbol relative to the
TLS pointer (which is stored at %gs:0x0).

3- The program then computes the address of the TLS variable by loading the
TLS pointer (the "mov %gs:0x0,%eax" instruction) and adding to it the symbols
TLS offset as stored in the GOT table (the updated "mov 0x0,%edx" instruction).

Cheers!  -Tyson

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

Aycan iRiCAN
Sorry, are there any advancements in dragonflybsd port of ghc?

--
aycan
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

G.Isenmann
On Thu, Nov 26, 2009 at 08:38:35PM +0200, Aycan iRiCAN wrote:
> Sorry, are there any advancements in dragonflybsd port of ghc?

I am still using the patches and the errno access wrapper, that were
attached to my last message.

If you need a bootstrap compiler, you can download
http://www.goetz-isenmann.de/dfly/ghc-6.10.4-dfly-5.tar.bz2, extract
this into /var/tmp, download
http://www.goetz-isenmann.de/dfly/liberrno_ptr.so, and put this into
/usr/pkg/lib.

Have not noticed any problems with this configuration so far.
And since this works for me, I currently prefer to learn haskell.

As time permits, I also like (a) to read about the upcoming ghc shared
library support, (b) to read the tls documentation, and (c) to get
something into pkgsrc, that will give use a working ghc for dragonfly
But I fear, that this will not happen during the next few weeks.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

Colin Paul Adams
In reply to this post by G.Isenmann
>>>>> "Goetz" == Goetz Isenmann <[hidden email]> writes:

    Goetz> My current strategie is, to avoid the problem in a first
    Goetz> step.

    Goetz> With the attached errno_ptr.{h,c} I create a shared
    Goetz> library, that encapsulates the errno access, install the
    Goetz> header file as /usr/pkg/include/errno_ptr.h and the shared
    Goetz> lib as /usr/pkg/lib/liberrno_ptr.so

    Goetz> Building ghc-6.10.4 with the attached patch (only a quick
    Goetz> hack, to check the idea) I get a result, that looks much
    Goetz> better.

    Goetz> @Colin: Maybe you can test and use this hack.

I've finally got round to trying this. I'm having a problem which
maybe has a simple known solution.

What I have done so far:

1) Built and deployed the shared library as detailed above
2) Applied the diff with patch <diff-name
3) cd chc-6.10.4
4) ./configure
5) make

Make immediately fails with:

"./mk/boilerplate.mk", line 41: Need an operator
"./mk/boilerplate.mk", line 44: Need an operator
"./mk/config.mk", line 29: Need an operator
"./mk/config.mk", line 30: Need an operator
"./mk/config.mk", line 31: Need an operator
"./mk/config.mk", line 32: Need an operator
"./mk/config.mk", line 33: Need an operator
"./mk/config.mk", line 169: Need an operator
"./mk/config.mk", line 171: Need an operator
"./mk/config.mk", line 173: Need an operator
"./mk/config.mk", line 196: Need an operator
"./mk/config.mk", line 210: Need an operator
"./mk/config.mk", line 268: Need an operator
"./mk/config.mk", line 270: Need an operator
"./mk/config.mk", line 272: Need an operator
Error expanding embedded variable.

I'm not exactly familiar with makefile syntax, so I could see anything
that rang alarm bells. Line 41 looks like:

ifneq "$(way)" ""


--
Colin Adams
Preston Lancashire
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

Thanos Tsouanas-2
On Tue, Dec 15, 2009 at 12:53 PM, Colin Paul Adams
<[hidden email]> wrote:

>
> [..snip..]
>
> I've finally got round to trying this. I'm having a problem which
> maybe has a simple known solution.
>
> What I have done so far:
>
> 1) Built and deployed the shared library as detailed above
> 2) Applied the diff with patch <diff-name
> 3) cd chc-6.10.4
> 4) ./configure
> 5) make

You should use gmake instead of make.

> Make immediately fails with:
>
> "./mk/boilerplate.mk", line 41: Need an operator
> "./mk/boilerplate.mk", line 44: Need an operator
>
> [..snip..]

--
Thanos Tsouanas
http://mpla.math.uoa.gr/~thanos/
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Porting to DragonFly BSD

Colin Paul Adams
In reply to this post by Colin Paul Adams
>>>>> "Karel" == Karel Gardas <[hidden email]> writes:

    Karel> Seeing DragonFly BSD and `make' together with your make
    Karel> error messages rings an alarm here with a suggestion to use
    Karel> GNU make.

That's a good alarm you have :-)

gmake works much better. Thanks.
--
Colin Adams
Preston Lancashire
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
12