On 21 February 2011 13:50, Ian Lynagh wrote:

Can you file a ticket...

Done: http://hackage.haskell.org/trac/ghc/ticket/4974

The problem (below) is caused by the new flags -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 inside hsc2hs that have been added to fix http://hackage.haskell.org/trac/ghc/ticket/4860. ./configure for the network package does not use these flags. So AI_NUMERICSERV is defined for 10.6 but not for 10.5. Christian Am 21.02.2011 11:14, schrieb Christian Maeder: [...]

I get an error when trying to cabal install network using http://www.haskell.org/ghc/dist/7.0.2-rc2/ghc-7.0.1.20110217-x86_64-apple-da...

C.

Configuring network-2.3.0.2... checking build system type... i386-apple-darwin10.6.0 checking host system type... i386-apple-darwin10.6.0 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for an ANSI C-conforming const... yes checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking for stdlib.h... (cached) yes checking for sys/types.h... (cached) yes checking for unistd.h... (cached) yes checking winsock2.h usability... no checking winsock2.h presence... no checking for winsock2.h... no checking ws2tcpip.h usability... no checking ws2tcpip.h presence... no checking for ws2tcpip.h... no checking wspiapi.h usability... no checking wspiapi.h presence... no checking for wspiapi.h... no checking arpa/inet.h usability... yes checking arpa/inet.h presence... yes checking for arpa/inet.h... yes checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking netinet/tcp.h usability... yes checking netinet/tcp.h presence... yes checking for netinet/tcp.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking sys/uio.h usability... yes checking sys/uio.h presence... yes checking for sys/uio.h... yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking for readlink... yes checking for symlink... yes checking for struct msghdr.msg_control... yes checking for struct msghdr.msg_accrights... no checking for struct sockaddr.sa_len... yes checking for in_addr_t in netinet/in.h... yes checking for SO_PEERCRED and struct ucred in sys/socket.h... no checking for _head_libws2_32_a in -lws2_32... no checking for getaddrinfo... yes checking for gai_strerror... yes checking whether AI_ADDRCONFIG is declared... yes checking whether AI_ALL is declared... yes checking whether AI_NUMERICSERV is declared... yes checking whether AI_V4MAPPED is declared... yes checking for sendfile in sys/sendfile.h... no checking for sendfile in sys/socket.h... yes checking for gethostent... yes configure: creating ./config.status config.status: creating network.buildinfo config.status: creating include/HsNetworkConfig.h config.status: include/HsNetworkConfig.h is unchanged Preprocessing library network-2.3.0.2... Socket.hsc: In function ‘main’: Socket.hsc:1848: error: ‘AI_NUMERICSERV’ undeclared (first use in this function) Socket.hsc:1848: error: (Each undeclared identifier is reported only once Socket.hsc:1848: error: for each function it appears in.) compiling dist/build/Network/Socket_hsc_make.c failed (exit code 1) command was: /usr/bin/gcc -c dist/build/Network/Socket_hsc_make.c -o dist/build/Network/Socket_hsc_make.o -m64 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -fno-stack-protector -D__GLASGOW_HASKELL__=700 -Iinclude -DCALLCONV=ccall -I/Users/Shared/maeder/lib/ghc-7.0.1.20110217/unix-2.4.2.0/include -I/Users/Shared/maeder/lib/ghc-7.0.1.20110217/bytestring-0.9.1.10/include -I/Users/Shared/maeder/lib/ghc-7.0.1.20110217/base-4.3.1.0/include -I/Users/Shared/maeder/lib/ghc-7.0.1.20110217/include -I/Users/Shared/maeder/lib/ghc-7.0.1.20110217/include -I/Users/Shared/maeder/lib/ghc-7.0.1.20110217/include/ cabal: Error: some packages failed to install: network-2.3.0.2 failed during the building phase. The exception was: ExitFailure 1

Am 21.02.2011 13:03, schrieb Max Bolingbroke:

On 21 February 2011 11:50, Christian Maeder wrote:

...

The problem (below) is caused by the new flags -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 inside hsc2hs that have been added to fix http://hackage.haskell.org/trac/ghc/ticket/4860.

./configure for the network package does not use these flags. So AI_NUMERICSERV is defined for 10.6 but not for 10.5.

I filed a bug against network for this issue ages ago: http://trac.haskell.org/network/ticket/35

I thought the 10.5 flags have been added to hsc2hs just recently. The problem is solved when removing them from hsc2hs. Maybe for GHC.framework/Versions/7.0.1.20101215 the -isysroot flag crept in differently. C.

It looks like it wasn't fixed after all :-(

Max

Am 21.02.2011 14:00, schrieb Kazu Yamamoto (山本和彦):

Hello,

...

The problem (below) is caused by the new flags -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 inside hsc2hs that have been added to fix http://hackage.haskell.org/trac/ghc/ticket/4860.

./configure for the network package does not use these flags. So AI_NUMERICSERV is defined for 10.6 but not for 10.5.

You need the latest Cabal library.

% cabal --version cabal-install version 0.9.5 using version 1.10.1.0 of the Cabal library

With this the cabal-install command, you can install the network package.

No, I've tried with: cabal-install version 0.9.6 using version 1.10.0.0 of the Cabal library (that I needed to install using ghc-7.0.1, because it needs network.) hsc2hs is the wrong! Christian

--Kazu

Just to double check. Is there a problem with the network library that I need to fix or is this just GHC/Cabal related? Johan

Am 21.02.2011 19:16, schrieb Ian Lynagh:

On Mon, Feb 21, 2011 at 05:44:54PM +0100, Christian Maeder wrote:

...

...

% cabal --version cabal-install version 0.9.5 using version 1.10.1.0 of the Cabal library

With this the cabal-install command, you can install the network package.

No, I've tried with:

cabal-install version 0.9.6 using version 1.10.0.0 of the Cabal library

You need 1.10.1.0 (the version that comes with RC 2).

Ah, yes this one works, although with: checking whether AI_NUMERICSERV is declared... no even if hsc2hs does not contain this isysroot stuff. Where does cabal get its flags from? (hardcoded?) @Johan: I don't think it is a problem of network library Cheers Christian

Am 22.02.2011 14:47, schrieb Ian Lynagh:

On Tue, Feb 22, 2011 at 09:59:20AM +0100, Christian Maeder wrote:

...

Where does cabal get its flags from? (hardcoded?)

From the "C compiler flags", "Gcc Linker flags" and "Ld Linker flags" entries in ghc --info's output.

Ok, they are not in bin/ghc script. So where does ghc get them from? Thanks Christian

Am 23.02.2011 15:41, schrieb Ian Lynagh:

On Tue, Feb 22, 2011 at 05:17:35PM +0100, Christian Maeder wrote:

...

Am 22.02.2011 14:47, schrieb Ian Lynagh:

...

On Tue, Feb 22, 2011 at 09:59:20AM +0100, Christian Maeder wrote:

...

Where does cabal get its flags from? (hardcoded?)

From the "C compiler flags", "Gcc Linker flags" and "Ld Linker flags" entries in ghc --info's output.

Since the sdk flags will be gone in ghc-7.0.3, re-adding them via the command-line will not pass them to cabal. Should not more flags be passed to cabal? Will there be no chance to produce 10.5 code on 10.6 machines? Can dtrace (and its problems) be disabled on macs? Modifying archives seems to scary: http://hackage.haskell.org/trac/ghc/ticket/4996 Thanks Christian

...

Ok, they are not in bin/ghc script. So where does ghc get them from?

Compiled into the compiler, from the cCcOpts/cGccLinkerOpts/cLdLinkerOpts variables in compiler/stage*/build/Config.hs

Thanks Ian

On Thu, Mar 17, 2011 at 02:03:15PM +0100, Christian Maeder wrote:

Am 17.03.2011 12:49, schrieb Christian Maeder:

...

Am 23.02.2011 15:41, schrieb Ian Lynagh:

...

On Tue, Feb 22, 2011 at 05:17:35PM +0100, Christian Maeder wrote:

...

Am 22.02.2011 14:47, schrieb Ian Lynagh:

...

On Tue, Feb 22, 2011 at 09:59:20AM +0100, Christian Maeder wrote:

...

Where does cabal get its flags from? (hardcoded?)

From the "C compiler flags", "Gcc Linker flags" and "Ld Linker flags" entries in ghc --info's output.

Since the sdk flags will be gone in ghc-7.0.3, re-adding them via the command-line will not pass them to cabal. Should not more flags be passed to cabal?

It still makes sense to pass these sdk flags, if one wants to produce portable binaries.

We can't support both 10.5 and XCode 4: http://hackage.haskell.org/trac/ghc/ticket/5011 Building GHC on 10.5 still ought to work (but we can no longer support it as a tier 1 platform). Thanks Ian

On Mon, Feb 28, 2011 at 04:08:55PM +0100, Christian Maeder wrote:

Am 28.02.2011 13:33, schrieb Christian Maeder:

...

Am 20.02.2011 22:16, schrieb Ian Lynagh:

...

We are pleased to announce the second release candidate for GHC 7.0.2:

http://www.haskell.org/ghc/dist/7.0.2-rc2/

I'm surprised this is already the second release candidate for GHC 7.0.2. The first release candidate was announced 16.12.2010 (and forgotten).

Well, we couldn't have another first RC :-)

...

Shouldn't there be a third candidate to be sufficiently tested?

There's a trade-off. Building testing, uploading, etc, another RC would be another 0.5-1 days work, and would put the release back by another week (which also puts back the HP release, the 7.2.1 release, and at this rate even the 7.4 release!).

I could not test much yet, due to http://hackage.haskell.org/trac/ghc/ticket/4972 and http://hackage.haskell.org/trac/ghc/ticket/4973

You mean that these stop you testing with the RC, rather than that you think they're still broken in the 7.0 branch, right? You don't say what package (and version of the package) you're using in #4972, so I can't test it myself. You can also test with a more recent nightly snapshot that has the fixes for bugs that you're encountering: http://www.haskell.org/ghc/dist/stable/dist/ The RCs just use a nightly snapshot as the source tarball. If there are no known issues, I plan to release 7.0.2 tomorrow, though! Thanks Ian

Am 28.02.2011 21:47, schrieb Ian Lynagh: [...]

week (which also puts back the HP release, the 7.2.1 release, and at this rate even the 7.4 release!).

Why are you talking about a 7.2.1 release and even 7.4? The GHC trac does not even have descriptions for those. Instead there's a milestone for 7.0.3 (although without description, too.) What important achievement (apart from the tickets listed) should I expect from a 7.2.1 release compared to 7.0.2 (or 7.0.3)? Thanks Christian