> :-P * * * Seriously: Should the configure script run tests
> via rsh/ssh? And
> what if the target platform can't be reached remotely? I've
> never seen such
> an autoconf trick before...
Just provide a script that can be run (by hand) on the target platform
and a way to port the results bac
Alastair Reid wrote:
This still feels like a brittle solution to me.
But an ABI is one of the most solid conventions on any platform, so I really
can't see a problem here.
I believe that testing what your actual machine does and does not support is
the right approach when not cross-compiling.
Gran
> Apart from [using platform-based tests], I can't see any other
> solution for this problem. Doing a runtime test on the build/host platform
> for a feature of the target platform is simply wrong...
This still feels like a brittle solution to me.
I believe that testing what your actual machine d
Alastair Reid wrote:
Tests needing a *target* machine are bad when it comes to
cross-compilation, so we should try to avoid this for GHC. OK, GHC is not
really capable of cross-compilation yet, but we shouldn't make things
worse.
This is a topic I haven't thought about much. What is the recomme
> I assumed that the nlist test would still be sufficient for other
> platforms, as it also correctly determined that Mac OS X itself uses
> symbols with underscores *everywhere* else.
I'm afraid not.
At least one of the BSDs has problems with it. (At least, it kept getting the
answer wrong for
Alastair Reid wrote:
Could I recommend that you use or adapt the autoconf test HUGS_TRY_DYNLINK
(hugs98/src/unic/aclocal.m4 in the same cvs repository that has ghc).
I would recommend against this. :-)
This test generates a C object file to be loaded then tries to load the object
file using one o
> While your patch should work, I remember seeing C code that uses
> function names like "foo" and "_foo" in the same way that a Haskell
> programmer might use foo and foo', so I had a bad feeling about
> automatically trying both.
Could I recommend that you use or adapt the autoconf test HUGS_T
On Thursday, September 11, 2003, at 11:27 AM, Wolfgang Thaller wrote:
Sorry for my silence in the past week.
While your patch should work, I remember seeing C code that uses
function names like "foo" and "_foo" in the same way that a Haskell
programmer might use foo and foo', so I had a bad feel
Gregory Wright wrote:
Hello,
I've fixed it in the darwinports version. I patched the linker to try
to find symbols
with and without a leading underscore. I thought I had sent a note to
the list
but perhaps I overlooked doing so.
The underlying issue is that there are versions of dlcompat using
Hi Wolfgang,
Thanks again for the prompt reply.
I did exactly as you noted below (removed the framework support check
from configure.in,
ran autoconf and ./configure, then built. Everything works appears to
work correctly but
ghci. (For example, I can build a network test program that queries
gwright:
>
> Hi,
>
> I've built ghc 6.0.1 under OS X 10.2.6 and have a curious
> problem with ghci. ghc seems to work fine, but ghci give me an
> error. I should note that I've done the build without
> Wolfgang's HaskellSupportFramework, by setting the include and
> library paths in build.mk. Th
I should note that I've done
the build without Wolfgang's HaskellSupportFramework, by setting the
include
and library paths in build.mk. This is more compatible with the
automated packing
scheme of DarwinPorts.
Of course. The HaskellSupport.framework isn't necessary when the user
already has Dar
On Wednesday, August 6, 2003, at 10:58 PM, Donald Bruce Stewart wrote:
gwright:
Hi,
I've built ghc 6.0.1 under OS X 10.2.6 and have a curious
problem with ghci. ghc seems to work fine, but ghci give me an
error. I should note that I've done the build without
Wolfgang's HaskellSupportFramework, b
Hi,
I've built ghc 6.0.1 under OS X 10.2.6 and have a curious problem with
ghci.
ghc seems to work fine, but ghci give me an error. I should note that
I've done
the build without Wolfgang's HaskellSupportFramework, by setting the
include
and library paths in build.mk. This is more compatible wi
14 matches
Mail list logo
