Re: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip

Hello, On Friday 04 January 2008 12:03, Christian Maeder wrote:
...
Thanks a lot for this response.
I'm not happy about this framework hick-hack either.
I am glad we agree about that.
I've only pushed it, because we needed a readline solution on macs.
I understand that there are problems in this area, but I am not convinced that they could not be solved without the renamed and/or modified readline library. I am sorry if you have done that already elsewhere, but I don't recall having seen any details about your difficulties. Would you be kind enough to supply some details? Thanks a lot.
The alternative is to use static linking of gmp (as suggested by chak) _and_ readline (version 5), so that user programs are also statically linked with these libs.
Again, I am not convinced that this is the only alternative.
... Regarding this actual GNUreadline-framework.zip replacement, this is harmless and seems to matter only for those who build ghc with frameworks (as only the inclusion of header files changed)
It is perhaps without any practical consequences, but I have seen many cases where circumstances managed to create the most glorious confusion out of the most innocently looking changes. So I would maintain that replacing something that you have published with something different is not a good idea.
In any case we should strive to fix the frameworks issues _and_ add support for static linking of gmp, readline and possibly other libs (plus license issues).
I fully agree with this. Ideally, the plan would be to, first, figure out what the ideal solution looks like. And then work towards that ideal solution. Making sure that what we introduce on the way as short-term hacks are clearly marked as such, to ensure that they don't impress themselves on people's minds as part of the final solution. I have every intention to work out some ideal (or perhaps more modestly: better) solution. But whether it will emerge in time to make any difference, remains to be seen.
HTH Christian
Thanks and best regards Thorkil

On Jan 5, 2008 10:29 AM, Thorkil Naur
On Friday 04 January 2008 12:03, Christian Maeder wrote:
I understand that there are problems in this area, but I am not convinced that they could not be solved without the renamed and/or modified readline library. I am sorry if you have done that already elsewhere, but I don't recall having seen any details about your difficulties. Would you be kind enough to supply some details? Thanks a lot.
The alternative is to use static linking of gmp (as suggested by chak) _and_ readline (version 5), so that user programs are also statically linked with these libs.
Again, I am not convinced that this is the only alternative.
There is another alternative (which I think we talked about before): Have ghc manually search for frameworks in the standard folders (rather than letting gcc do it automatically). Then if we found e.g. /Library/Frameworks/GNUreadline.framework, we would pass the following flag: -I/Library/Frameworks/GNUreadline.framework/Versions/A/Headers In that case, we would not need modified readline headers. However, I really don't like the above, since we're reimplenting something gcc gives us for free. And if we *do* rely on gcc's standard searching (as is the case now), then I agree with Christian that modified headers are necessary for GNUreadline to work as a framework. Also, the script that builds GNUreadline.framework modifies the header files automatically. So I don't think it's any worse than, say, pre-processing a library as part of a MacPorts distribution.
... Regarding this actual GNUreadline-framework.zip replacement, this is harmless and seems to matter only for those who build ghc with frameworks (as only the inclusion of header files changed)
It is perhaps without any practical consequences, but I have seen many cases where circumstances managed to create the most glorious confusion out of the most innocently looking changes. So I would maintain that replacing something that you have published with something different is not a good idea.
I looked into this, and frameworks do already support versioning: http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Conc... In particular, one framework can contain multiple versions. So currently GNUreadline.framework contains: Versions/A/GNUreadline (object code file) Versions/A/Headers (a folder containing header files) GNUreadline (symlink to `Versions/A/GNUreadline`) Headers (symlink to `Versions/A/Headers`) And we could distribute instead a GNUreadline.framework which contains: Versions/A/GNUreadline (object code file) Versions/B/GNUreadline (symlink to the above) GNUreadline (symlink to Versions/A/GNUreadline) Versions/A/Headers (a folder containing unmodified headers) Versions/B/Headers (a folder containing modified headers) Headers (symlink to Versions/B/Headers) The above makes version B the default, but version A is still available if you want it. We could do something similar when upgrading to readline 6.0 if it ever comes out. Finally, we could also change the name of the .zip file to reflect the version of the framework, so that users don't confuse the two downloads. Would the above make the modified GNUreadline feel like less of a hack? Best, -Judah

Judah Jacobson wrote:
On Jan 5, 2008 10:29 AM, Thorkil Naur
wrote: On Friday 04 January 2008 12:03, Christian Maeder wrote:
I understand that there are problems in this area, but I am not convinced that they could not be solved without the renamed and/or modified readline library. I am sorry if you have done that already elsewhere, but I don't recall having seen any details about your difficulties. Would you be kind enough to supply some details? Thanks a lot.
I'm against a further (renamed or modified) readline library (and I've done nothing in that direction).
The alternative is to use static linking of gmp (as suggested by chak) _and_ readline (version 5), so that user programs are also statically linked with these libs.
I just have succeeded in linking ghc-6.8.2 statically with libreadline.a and libncurses.a in the compiler directory by setting: SRC_HC_OPTS += -optl-Xlinker -optl-search_paths_first in mk/build.mk. This option prevents linking against the wrong dynamic library /usr/lib/libreadline.dylib.
Again, I am not convinced that this is the only alternative.
I don't see an advantage of a renamed or modified readline library (it'll be even more version confusion).
There is another alternative (which I think we talked about before):
yes in http://hackage.haskell.org/trac/ghc/ticket/1798
Have ghc manually search for frameworks in the standard folders (rather than letting gcc do it automatically). Then if we found e.g. /Library/Frameworks/GNUreadline.framework, we would pass the following flag: -I/Library/Frameworks/GNUreadline.framework/Versions/A/Headers
It's not even necessary to specify a version. Enough is: -I/Library/Frameworks/GNUreadline.framework/Headers or in $HOME: -I$HOME/Library/Frameworks/GNUreadline.framework/Headers
In that case, we would not need modified readline headers.
This way I wanted to go before (saving some -F trouble for some -I trouble), but proper mac frameworks should also have proper mac framework headers.
However, I really don't like the above, since we're reimplenting something gcc gives us for free. And if we *do* rely on gcc's standard searching (as is the case now), then I agree with Christian that modified headers are necessary for GNUreadline to work as a framework.
yes. [...] With static linking the whole framework issue may become obsolete. Cheers Christian

On Jan 7, 2008 6:55 AM, Christian Maeder
Judah Jacobson wrote:
On Jan 5, 2008 10:29 AM, Thorkil Naur
wrote: The alternative is to use static linking of gmp (as suggested by chak) _and_ readline (version 5), so that user programs are also statically linked with these libs.
I just have succeeded in linking ghc-6.8.2 statically with libreadline.a and libncurses.a in the compiler directory by setting:
Readline is distributed under the GPL, not the LGPL (which gmp is). Does the above cause a licensing problem? (I don't have much experience in that area; hopefully someone can explain this issues involved.) Thanks, -Judah

On Mon, Jan 07, 2008 at 09:19:25AM -0800, Judah Jacobson wrote:
On Jan 7, 2008 6:55 AM, Christian Maeder
wrote: Judah Jacobson wrote:
On Jan 5, 2008 10:29 AM, Thorkil Naur
wrote: The alternative is to use static linking of gmp (as suggested by chak) _and_ readline (version 5), so that user programs are also statically linked with these libs.
I just have succeeded in linking ghc-6.8.2 statically with libreadline.a and libncurses.a in the compiler directory by setting:
Readline is distributed under the GPL, not the LGPL (which gmp is). Does the above cause a licensing problem? (I don't have much experience in that area; hopefully someone can explain this issues involved.)
Perhaps the best answer is for someone to make editline bindings for Haskell? I believe this would solve the problem twice: OS X comes with editline, and it's BSD licensed so we can happily statically link against it. The latter may help us on Windows too. Everything I know about editline is third-hand, but AIUI the APIs are very similar, so it shouldn't be hard to alter GHC to use editline instead. Thanks Ian

On Jan 7, 2008 11:46 AM, Ian Lynagh
On Mon, Jan 07, 2008 at 09:19:25AM -0800, Judah Jacobson wrote:
On Jan 7, 2008 6:55 AM, Christian Maeder
wrote: Judah Jacobson wrote:
On Jan 5, 2008 10:29 AM, Thorkil Naur
wrote: The alternative is to use static linking of gmp (as suggested by chak) _and_ readline (version 5), so that user programs are also statically linked with these libs.
I just have succeeded in linking ghc-6.8.2 statically with libreadline.a and libncurses.a in the compiler directory by setting:
Readline is distributed under the GPL, not the LGPL (which gmp is). Does the above cause a licensing problem? (I don't have much experience in that area; hopefully someone can explain this issues involved.)
Perhaps the best answer is for someone to make editline bindings for Haskell?
I believe this would solve the problem twice: OS X comes with editline, and it's BSD licensed so we can happily statically link against it. The latter may help us on Windows too.
Everything I know about editline is third-hand, but AIUI the APIs are very similar, so it shouldn't be hard to alter GHC to use editline instead.
Editline provides readline/[readline.h,history.h] which provide a subset of the readline API and (I've checked) contain all of the functions that ghci uses. One possiblility is to add a configure --with-libedit flag to the readline package which would permit linking against libedit and #ifdef out all functions that it doesn't support. Note that the package already #defines HAVE_READLINE_4 and HAVE_READLINE_5 to permit compiling against multiple versions of readline, so adding HAVE_GNU_READLINE or HAVE_LIBEDIT wouldn't be much worse, IMHO. Best, -Judah

Ian Lynagh wrote:
On Mon, Jan 07, 2008 at 09:19:25AM -0800, Judah Jacobson wrote:
On Jan 7, 2008 6:55 AM, Christian Maeder
wrote: Judah Jacobson wrote:
On Jan 5, 2008 10:29 AM, Thorkil Naur
wrote: The alternative is to use static linking of gmp (as suggested by chak) _and_ readline (version 5), so that user programs are also statically linked with these libs. I just have succeeded in linking ghc-6.8.2 statically with libreadline.a and libncurses.a in the compiler directory by setting: Readline is distributed under the GPL, not the LGPL (which gmp is). Does the above cause a licensing problem? (I don't have much experience in that area; hopefully someone can explain this issues involved.)
Perhaps the best answer is for someone to make editline bindings for Haskell?
I don't *think* libedit provides the completion functionality that we use in GHC, but I could be wrong. Cheers, Simon
participants (5)
-
Christian Maeder
-
Ian Lynagh
-
Judah Jacobson
-
Simon Marlow
-
Thorkil Naur