Karim Belabas on Tue, 12 Mar 2013 16:42:08 +0100 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: OS X dmg image |
* Pascal Molin [2013-03-11 23:30]: > Last try for today : > http://pari.math.u-bordeaux1.fr/~pascal/PariGP-2.5.3.dmg > > I did not know what to do with some links from libreadline to libgcc and > libncurses, I hope this will do. Hi Pascal, I had started working on exactly the same project last week and was about to release it ! :-) I had proceeded as follows to build gp : #!/bin/sh # from MacPorts, to avoid the broken Xcode compiler export CC=gcc-mp-4.7 # to avoid linking with libgcc_s.dylib export LDFLAGS=-static-libgcc # 1) --graphic=none: disable fltk, brings in too many dylib & frameworks # 2) use MacPorts'readline, avoid broken editline ./Configure --graphic=none --with-readline=/opt/local # override GMPLIBS/RLLIBS values to make sure we link with .a, not # dylibs. -static doesn't work cd Odarwin-i386 && make\ GMPLIBS=/opt/local/lib/libgmp.a\ RLLIBS="/opt/local/lib/libreadline.a /opt/local/lib/libcurses.a"\ gp-sta N.B. I disable fltk & hi-res graphics ( which *sort of* works on my system but would drag in further dylibs and frameworks, and requires extra patches to fix pari-daemon(), given CoreFoundation's broken fork() concept, see bug #1354. ) This produces a stand-alone gp-sta, depending only on libSystem and incorporating both readline and gmp: (16:10) kb% otool -L gp-sta gp-sta: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) (16:10) kb% About your second problem, building a relocatable application able to use paths relative to the installation directory, we have no real support for this. We have fledgling ad hoc constructions for the Windows binary, but it's not suitable for generalizaion yet. Also, on OS/X, we have the standard /usr/local hierarchy. So my gp-sta is meant to be installed in /usr/local/bin. In order to interact smoothly with gphelp and optional packages, it expects the latter to be installed in the standard places under /usr/local/. Those can be overriden using defaults 'datadir', 'help', 'prettyprinter' and environment variable 'GPDOCDIR', if the user knows what she's doing (and we can build a startup script for all that once we know the name of the installation directory) but it's much simpler to use the standard locations. I had started to play with dmg's as well but had decided against it in the end in particular for this reason; the other being that I didn't want to distribute a full-fledged 330MB distribution and didn't see a way to distribute "incremental" dmg's in more than one monolithic step. In the end, I found it simpler to distribute a standalone gp-sta + all basic files (gphelp, doc/translations, doc/usersch*.tex) + a trivial install.sh that just copies all those files to the default /usr/local/ places. From a user's point of view, this requires: 1) extracting a .tar.gz (or zip ?) archive 2) opening a Terminal there and typing 'sudo install.sh' Users can also copy (once!) all extra optional packages they require to /usr/local/share/pari This might feel a little awkward to Mac users since it requires to use the Terminal rather than dragging some icon to an Application folder. But it should "just work" with minimal effort. Maybe you can find a solution to accomodate both ways ? Cheers, K.B. P.S: I'm on holiday right now, I was planning to release the above by the end of the week. -- Karim Belabas, IMB (UMR 5251) Tel: (+33) (0)5 40 00 26 17 Universite Bordeaux 1 Fax: (+33) (0)5 40 00 69 50 351, cours de la Liberation http://www.math.u-bordeaux1.fr/~belabas/ F-33405 Talence (France) http://pari.math.u-bordeaux1.fr/ [PARI/GP] `