Urania

A blog named for the muse of Astronomy containing musings by an astronomer

Archive for the ‘X11’


PGPLOT on Mountain Lion 0

Posted on October 20, 2012 by Juan

One of the most popular posts I made on this site was back in 2009 when I wrote about how I got  the increasingly dated PGPLOT package put together by Tim Pearson running under Snow Leopard.  I decided to update that entry to how I approach things today, using homebrew as a package manager under Mountain Lion.  Honestly, these days I do most of my programming and plotting with Python and matplotlib, but I still have old code that needs to be run sometimes, so getting PGPLOT running under Mountain Lion allows me to keep that old software running.

  1. Install X11: You will need to install XQuartz in order to have XWindows support for PGPLOT.  Grab the package installer and install it.
  2. Install Homebrew:   Intall the homebrew package manager.
  3. Install GFORTRAN: The first thing you need to do after installing homebrew isinstall Gnu Fortran (aka gfortran).  This is fairly simple.  All you need to do is say:
    brew install gfortran
    There is a glitch here.  For some reason, the home-brew version of gfortran doesn’t bother to link the gfortran libraries from /usr/local/lib.  To workaround this,  symbolically linked them using:

    ln -s /usr/local/Cellar/gfortran/4.2.4-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/libgfortran.a /usr/local/lib/libgfortran.a
    ln -s /usr/local/Cellar/gfortran/4.2.4-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/libgfortranbegin.a /usr/local/lib//libgfortranbegin.a
    ln -s /usr/local/Cellar/gfortran/4.2.4-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/libgfortranbegin.la /usr/local/lib//libgfortranbegin.la

    The exact path to the original gfortran libraries may change if you install a newer version of gfortran! 
     
  4. Once they are installed, you simply have to make sure /usr/local/bin is in your $PATH.
     
  5. Install PGPLOT: I grabbed the PGPLOT source code from Tim Pearson’s website (here) and untarred the tarball into /usr/local/src/pgplot, the default location the code expects to be in (based on the instructions in the install-unix.txtfile included in the source code tarball).
    sudo tar -C /usr/local/src/ -xzvf pgplot pgplot5.2.tar.gz
  6. Install sys_macosx configuration: The PGPLOT source code has various compiler configurations stored in “configuration directories” but it doesn’t come with one for Mac OS X.  I ended up hacking the sys_macosx/ configuration directory to include a gfortran configuration. I have made a tarball of that configuration directory available in the pgplot5.2_macosx_addition.tgz that you can download and unpack into the PGPLOT source directory using:
    sudo tar -C -xzvf /usr/local/src/pgplot5.2_macosx_addition.tgz
  7. Compile the PGPLOT binaries: At this point, if you follow the instructions in the install-unix.txtfile in the PGPLOT directory you will be fine, baring in mind the configuration you want to use is the “maxosx gfortran_gcc” configuration. However, I will outline the steps I used below.
     
  8. Create a PGPLOT library/binary directory:Create a directory to contain the PGPLOT libraries. I created /usr/local/pgplot using the command:
    sudo mkdir /usr/local/pgplot
  9. Choose the graphics drivers you want:Copy the drivers.list file from the source directory to this new pgplot directory and edit it to match your needs:
    cd /usr/local/pgplot
    sudo cp /usr/local/src/pgplot/drivers.list .
    sudo vi drivers.list

    (You can replace this last step with emacs or whatever text editor you prefer). You make a graphics driver part of the compilation by removing the leading exclamation point from the line. I choose to activate the X-Window drivers, the GIF drivers (to create GIF images), and the PostScript printer drivers (which you can use to create PostScript versions of plots for publication). Be aware PNG support requires libpng be installed.
     
  10. Create the makefile: We now need to create the makefile using PGPLOT’s makemake script. Within the /usr/local/pgplotdirectory execute:
    sudo /usr/local/src/pgplot/makemake /usr/local/src/pgplot  macosx gfortran_gcc

    which should result in the following output
    Reading configuration file: /usr/local/src/pgplot/sys_macosx/gfortran_gcc.conf
    Selecting uncommented drivers from ./drivers.list
    Found drivers GIDRIV NUDRIV PSDRIV XWDRIV
    Creating make file: makefile
    Determining object file dependencies.
  11. Create all the binaries: Now you just have to create all the binaries, which is a simple makecommand:
    sudo make

    Assuming everything proceeds without error, you should then see at the end of the output
    *** Finished compilation of PGPLOT ***
    
    Note that if you plan to install PGPLOT in a different
    directory than the current one, the following files will be
    needed.
    
           libpgplot.a
           libpgplot.dylib
           grfont.dat
           rgb.txt
           pgxwin_server
    
    Also note that subsequent usage of PGPLOT programs requires that
    the full path of the chosen installation directory be named in
    an environment variable named PGPLOT_DIR.

    At this point, you should (if you are going to use PGPLOT within perl or C compile the C library as well using
    sudo make cpg

    Finally, clean out all the temporary object files, you don’t need them. Do this using the makefile by typing
    sudo make clean

    If you want to test if things are working you can run one of the PGPLOT demo programs created in this directory. However, the pgdemo* executables seem hard coded to expect the pgplot libraries in the /usr/local/lib directory, to it might be a good idea to do the following step before trying the demos. 
     
  12. Link library and header files: This step is optional, but since most programs (including the pgdemo* executables) don’t look in /usr/local/pgplot for library and header files, I symbolically linked the versions in the /usr/local/pgplot directory to /usr/local/lib and /usr/local/include respectively using
    sudo ln -s /usr/local/pgplot/libcpgplot.a /usr/local/lib/libcpgplot.a
    sudo ln -s /usr/local/pgplot/libpgplot.a /usr/local/lib/libpgplot.a
    sudo ln -s /usr/local/pgplot/libpgplot.dylib /usr/local/lib/libpgplot.dylib
    sudo ln -s /usr/local/pgplot/cpgplot.h /usr/local/include/cpgplot.h
  13. Making sure I use these PGPLOT binaries: Since I am using SciSoft OSX, I modified my ~/.tcshrcfile to change the PGPLOT related environmental variables after loading SciSoft’s environment
    setenv PGPLOT_DIR /usr/local/pgplot/
    . If you are not using Scisoft, you can place these lines anywhere in your ~/.tcshrc file. If you stick to using bash, then the corresponding lines in the ~/.bashrcfile that you need to create (after setting up Scisoft, if you are using that) are:
    export PGPLOT_DIR=/usr/local/pgplot/
    At this point you have a working PGPLOT set of libraries installed. 
     
  14. Installing PGPLOT support in Perl: You can stop here if you just want to use PGPLOT from C or FORTRAN source code. If you want to use PGPLOT from within Perl, you need to go further.
    1. Install the ExtUtils:: F77 perl module: In order to install PGPLOT support, you need to install ExtUtils:F77 first. You can download ExtUtils::F77 here and once you untar the tarball,
      tar xzvf ExtUtils-F77-1.17.tar.gz

      It can be easily compiled using the following standard perl module compilation steps:
      cd ExtUtils-F77-1.17
      perl Makefile.PL
      make
      sudo make install
    2. Install the PGPLOT perl module: You can download PGPLOT here. Untar the tarball.
      tar xzvf PGPLOT-2.21.tar.gz

      We start as we usually do for Perl modules, creating the makefile using the Makefile.PL script:
      cd PGPLOT-2.21

      Unfortunately, the Makefile.PL script will create a makefile this creates doesn’t work because it doesn’t call gfortran so we have to change the Makefile.PL script to know about gfortran. So load Makefile.PL and edit the line that reads
      use ExtUtils::F77;

      to read
      use ExtUtils::F77 qw{Darwin GFortran};

      Once you have done that, create the makefile using
      perl Makefile.PL

      Once you have done that, you can finish installing the perl module using:
      make

      you will see some warnings related to missing type specifiers and non-void functions.  Ignore them and continue
      make test
      sudo make install

      I was able to get the make test to work once I had the proper environmental variable settings for PGPLOT_DIR (see step 13).

So that is it, I now have working PGPLOT installations with perl support on my Mountain Lion Macs.

XQuartz on MacOS X for the Astronomer 0

Posted on May 28, 2009 by admin

When I first started this blog, I was using Apple’s built-in X11, but then with the transition to MacOS 10.5, there were some serious issues with Apple’s X11 implementation having to do with the transition from X11R6 to X.org. One of Apple’s programmers started putting out bleeding-edge updates to Apple’s X11 called XQuartz that fixed a lot of the programs and I have kept using it ever since.

Two years ago, I wrote a blog entry with hints for setting up X11 for the astronomer. The problem is that while the hints in that writeup are still valid, they don’t work if you are using Xquartz because the preferences are stored in a different location for XQuartz versus the built-in X11. As such, I am reproducing those X11 hints here, but with the edits necessary for use with XQuartz.

Once you have installed XQuartz, the X11.app should automatically launch when a program that needs X11 is executed (If you are an old hand at X11, you probably discovered since moving to Leopard that you should NOT set the DISPLAY variable to :0 to display an Xwindow on your primary display, just leave DISPLAY undefined.):

  1. There are many hidden preferences in XQuartz just like in many Mac Applications. You can see a list of the hidden (and not hidden) preferences using the command line tool defaults. To see the available XQuartz preferences, type:defaults read org.X.x11NOTE: If you are still using Apple’s built-in X11 implementation (or if you are using MacOS 10.4), just replace ‘org.x.X11’ with ‘com.apple.x11’ in all the following hints.
  2. In addition to “reading” the preferences, you can write to them. From the command line you can type:
    • defaults write org.X.x11 no_quit_alert true
      This allows X11 to quit without an alert box. Useful if you find it irritating like I do that X11 will prevent me from logging out or the computer from restarting due to that dialog box. However, this does mean you can accidentally quit X11.app pretty easily if you hit cmd-Q at the wrong time.
    • defaults write org.X.x11 wm_ffm true
      Allows which X11 window is selected to follow the mouse, which is the way X11 behaves under most *nix systems by default.
    • defaults write org.X.x11 wm_click_through -bool true
      This activates click_thorough events in the Quartz window manager, which allows clicks to pinned windows, another behavior common to *nix X11 installations.
  3. You can control which window manager is launched (if you prefer something other than the quartz-wm used by default). If you don’t have a ~/.xinitrc file, copy the default one:
    cp /private/etc/X11/xinit/xinitrc ~/.xinitc

    and then manipulate it with any text editor.
  4. BIG LAPTOP USER HINT: Because XQuartz on the Macintosh uses authentication to prevent connections from unauthorized sources to the X11 client, something interesting happens when you change IP address, you will discover you can’t use X11.app from the MacOS X Terminal until you quite and relaunch X11.app. This happens to me all the time on my laptop when I travel and the IP address changes. I recommend either using the Xterm as your terminal or just get used to restarting X11 if you have problems connecting to the terminal.
  5. You can run X11 remotely on your Mac, if you can ssh into your Mac, then just use
    ssh -Y youraccount@yourcomputer.com

    , the -Y flag should allow you to run X11 remotely as long as X11.app is running on your machine before the connection is made. If your ssh on the remote machine doesn’t support X11 connections and you have admin access, you can edit the file /etc/sshd_config on the remote machine and make sure X11 Forwarding is turned on by looking for the following lines and making sure they are uncommented and that all “no”’s are set to “yes”:
    X11Forwarding yes
    X11DisplayOffset 10
    X11UseLocalhost yes

And that is it for the hints for now.

X11 Updated, but requires unavailable OS X release! 0

Posted on April 24, 2009 by Juan

I just noticed that the XQuartz folks released X11 2.3.3, but when I attempted to install it, it said I needed Mac OS 10.5.7 installed, which hasn’t been released yet. I have confirmed this on the release notes page. The full release notes seem to describe to major changes, updated support for OpenGL and some bug fixes regarding Caps Lock and mouse tracking.

Interestingly, the XQuartz wiki notes that

[MacOS] 10.5.7 updates the X11 server to match what shipped with 2.3.2. Most of the userland, however, only saw security updates. The version reported by X11 in 10.5.7 is 2.1.6 to distinguish it from the 2.3.x series which contains a much newer userland.

I have the feeling that the update to MacOS 10.5.7 will be released very soon now.

[UPDATE: In fact, it took almost two weeks, but MacOS 10.5.7 was released on Tuesday, May 12, 2009.]

X11 for Leopard now supporting Full Screen 0

Posted on March 30, 2009 by Juan

There are some older school astronomers on Macs who cut their teeth on Linux and as such really prefer the full-screen X-Windows display for running astronomical data reductions. This way of running X11 has been unavailable since MaxOS 10.5 (which switched from X11 code bases). Well, to quote Macros Huerta’s MacSingularity Blog:

Well, I’m way late to the game on this, but our long national nightmare is over – Xquartz for Leopard support full screen!

The Xquartz folks latest edition of Xquartz (version 2.3.2.1) includes full-screen support. Now, personally, I like the way X11 integrates with Aqua, but for those who prefer to use only one windowing system at a time, you can now do it on MacOS X Leopard. You can download it here.

Two Astronomically Interesting Mac Software Updates Today 0

Posted on July 19, 2008 by Juan

Today I noticeed two interesting software updates for Mac-based professional astronomers.

The first one I noticed was the updating of Xquartz to version 2.3.0. Xquartz is the updated version of X11 for the Mac OS (even ahead of Apple’s own installed versions) that I prefer to use, largely because bug-fixes get rolled in here before they appear in Mac OS. This version requires Mac OS 10.5.4 and has a couple of caveats attached to it for programmers, notably:

The software supporting the deprecated imake build system is not provided in this package. If you need imake and xmkmf, please install the X11 package that came with your Leopard DVD before installing this version. Alternatively, you can compile these packages on your own or get them from a third party such as Fink or MacPorts. The darwin configuration files used by the imake build system are outdated and not supported. Developers using this build system are advised to migrate to autoconf.

[Added July 24, 2008: Apparently, this version of Xquartz changed the X11.app Icon so it now X11 looks like this

New X11 Icon

when it is on the Dock. Interesting, but it threw me for a second. The only documentation I found of this change is in a Ticket filed with XQuartz’s bug reporting system. Still, I think this is a good idea, as it gives a visual cue that you are using XQuartz as opposed to the default X11 installation.]

Along with a bunch of library changes, the key update appears to be having the Xserver updated to the 1.4 branch of Xorg. There is also “support for adding new $DISPLAY sockets after the server is running” (which I think means using the DISPLAY variable will not break things) and “/usr/X11/bin/Xquartz is just a stub that will ‘do the right thing’,” whatever that means. I have upgraded to it and as a reminder, if you upgrade MacOS after installing Xquartz, you will need to reinstall Xquartz to get it back.

The other interesting software release for Mac-based astronomers I noticed today was SAOImage DS9 which has released version 5.3beta, which appears to be, based on the statement on their homepage that “MacOSX 10.5 users with firewall enabled, please use version 5.3 beta”, geared toward addressing the issue I noticed this April with version 5.2 where launching SAOimage DS9 with a certain firewall setting on the Mac could result in the the application becoming irreparably damaged at launch.

Xquartz 2.2.3 released 0

Posted on June 26, 2008 by Juan

I was trying to upgrade wine within MacPorts when I realized I had forgotten to upgrade Xquartz after my upgrade to MacOS 10.5.3 on my Mac Pro. So I checked, Xquartz has been upgraded to version 2.2.3. Since version 2.2.1 (which I talked about in my blog here).

  • Upgraded the freetype library to version 2.3.6, which fixes “A bunch of potential security problems have been found [and fixed in this release”
  • Upgraded to pixman library to version 0.11.4.
  • Xquartz fixes from xorg-server-1.3.0-apple21, the key fix being support for monitor hotplugging, although several security fixes also occurred.

Again, if you upgrade MacOS (say to version 10.5.4, which is supposed to be released soon in order to support iPhone G3 and MobileMe), you will likely need to reinstall Xquartz (unless Apple has upgraded their X11 installation to match Xquartz).

Xquartz goes to version 2.2.1 0

Posted on May 06, 2008 by Juan

The Xquartz project is a useful one for Leopard users of astronomical applications because of the dependence of most astronomical applications on X11. A few days ago (what can I say, its finals and I am swamped with exam writing and grading) they released version 2.2.1. It contains all the tweaks that made it into the previous version and also includes

  • All packages updated to versions intended to ship as part of X11R7.4 (as of 2008.04.21).
  • Fixed multiple crash-causing bugs in the server.
  • Fixed cmd-tab to properly move all windows forward when entering X11.app.
  • Cleaned up multi-monitor support (still not completely bulletproof) [I have 2 monitors, so this is a big one for me].

As I have noted before, Apple includes some of the work done in this project in OSX updates, so it is suggested that you install the latest XQuartz release after updating to 10.5.2 (and any future 10.5.x or security updates).

SAOImage DS9 versus Leopard Firewall 2

Posted on April 22, 2008 by Juan

Immediately after installing SAOImage DS9 5.2, I had a major failure of the application and initially I just thought it was some sort of build bug. This is what I posted at that time:

[HOLD OFF ON THIS UPDATE! I have discovered that at least on one of my systems, this version of ds9 is refusing to run properly. It launched once, but when I attempted to check the “About SAOImage DS9”, it triggered the following error:

 “An internal error has been detected local header mismatch couldn’t open “zvfsmntpt/doc/sun.gif”: no such file.

(this occurred in both Aqua and X11 versions). Furthermore, all future attempts to launch ds9 (again, either Aqua or X11) fail with the following error:

Error in startup script: couldn’t read file “./zvfsmntpt/src/ds9.tcl”: no such file or directory  

Even removing the preferences file at ~/.ds9.prf didn’t help.]

Apparently, my problems with SAOImage DS9 in Leopard are a known issue. If you configure the built-in Firewall to “Set access for specific services and applications” so that you can approve “holes” in your firewall on an Application by Application basis, your first launch of SAOImage DS9 will irreparably damage the application!  Unfortunately, Apple implements the application firewall in part by modifying the Application package of the Application you are running by digitally signing it if it was not digitally signed by the developer (adding a file called CodeResources to the Application package). According the Apple’s documentation on this:

If you run an unsigned application not in the Application Firewall list, you will be presented with a dialog with options to Allow or Deny connections for the application. If you choose Allow, Mac OS X 10.5 will sign the application and automatically add it to the Application Firewall list. If you choose Deny, Mac OS X 10.5 will sign the application, automatically add it to the Application Firewall list and deny the connection.

So basically,Apple doesn’t warn you in the dialog box that comes up that it has whatever decision you make, it will modify the application by digitally signing it and it doesn’t give you a way to avoid this. This is, in my opinion, is an incredibly boneheaded move on Apple’s programmer’s part. They readily admit that

  Some applications check their own integrity when they are run without using code signing.

They suggest the application firewall will try to automatically detect these and avoid modifying them, but they should give you, the user, the option instead of making the decision via some internal algorithm.  MacOS X shouldn’t assume its OK to change an application. In the case of SAOImage DS9, they are irreparably damaging the application without leaving you a way to avoid the damage once you trigger the application firewall. Shame on you Apple. The only way to fix it is to reinstall the application!

So when I figured this out (a tip of the hat to this post on IRAF.net). I reinstalled the SAOImage DS9 executables (both Aqua and X11 versions) and before launching them, I set the Firewall (via the Security Pane of the System Preferences) to “Allow all incoming connections” (this is the default mode, so it is as secure as MacOS Tiger was). Everything now appears to work just fine.

Personally, I believe an application that fails its checksum should present a message indicating that is the problem instead of just crapping out, but in this case, the fault lies mostly with Apple. Apple is damaging applications by making this critical decision in the background, without user intervention!

DS9 version 5.2 released 1

Posted on April 19, 2008 by Juan

[See my more recent post warning about MacOS X Firewall settings and how they can destroy the SAOImage DS9 executable during its first launch! This problem is avoidable by tweaking the Firewall settings, but once you have launched SAOImage DS9 with the bad settings, the application is damaged can can’t be relaunched again. A reinstallation is the only solution, so it is a good idea to avoid this problem.]

The folks in Cambridge have kept busy. They have released SAOImage DS9 version 5.2. The versions for MacOS X include the following:

The rather extensive changes are detailed in the release notes here, but the notable ones to me include:

  • ANALYSIS: for MacOSX tiger, wrap cmds with shell and PATH.
  • GUI: change default directory for standard dialog to $HOME.
  • ANALYSIS: add /sw/bin to default path for MacOSX. While unstated in the release notes, this is clearly an attempt to support Fink, which places its installation in the /sw directory.
  • GUI: ds9 will now start in the users home directory for MacOSX Aqua users when invoked from a double click and the default dialog box is Motif or Windows.
  • MACOSX: fixed a problem with printing non standard colors.
  • MACOSX: restore postscript printing.
  • REGIONS: apply WCS to fits regions if present.
  • GUI: add support for user configured button bar.
  • CATALOGS: add support for simbad.
  • IMEXAMINE: added support for key stroke events.
  • Although unstated in their release notes, they are now apparently providing universal binaries instead of PPC and Intel binaries for MacOS X.

I have previously posted notes for integrating upgrades of DS9 into the Scisoft OS X installation and they still work just fine.

XQuartz updated to version 2.2.0.1 1

Posted on April 14, 2008 by Juan

[This originally linked to version 2.2.0, but there was a security related bug in version 2.2.0, so this release has appeared to replace it.]

The Xquartz folks have updated Xquartz to version 2.2.0.1. Xquartz is an effort to provide a better X11 server for Leopard than Apple provides, being proactive in providing fixes Apple will likely include later. The release notes are long and cover a bunch of updates to various items, including:

  • Added informational output when falling through to failsafe startup in X11.app
  • Unsetenv(DISPLAY) when falling through to failsafe startup in X11.app
  • Exposé now works as expected
  • X11 works better with spaces

I suspect the discussion of ‘failsafe’ startups is to provide a more informational failure than what was happening before for people like myself who transitioned from previous MacOS X installations and had been manually forcing the DISPLAY variable to point to :0.0, which is somewhat standard in the Unix world.

I’d recommend grabbing this Xquartz update and applying it if you use Leopard and astronomical software. Its a double-click install. Apple does watch this project (one of the developers is Apple’s X11 developer), and as noted on the Xquartz site:

Apple included some of the work done in this project in their 10.5.2 update and will likely include further changes in possible future updates of 10.5.x. It is suggested that you install the latest XQuartz release after updating to 10.5.2 (and any future 10.5.x or security updates).

In other words, while some of these fixes will likely end up in the official MacOS released by Apple, if you want them now, use Xquartz. Furthermore, since Xquartz does over-write Apple’s default X11 install, this means that if Apple upgrades X11 in a future patch, you could end up with a broken install if you used Xquartz. Personally, I haven’t had a problem, but I suggest you keep the Xquartz package around, and re-install it after any future MacOS X updates.

Site upgrade to Leopard 0

Posted on March 04, 2008 by Juan

I have taken part of my day to get my main web server upgraded to MacOS X 10.5 (aka Leopard). I spent quite a bit of time waiting, removing programs I knew were incompatible, and so on. Still, this upgrade was not without a few bumps:

  • Check Hardware Compatibility: My Sonnet Tempo SATA X4P card (which I use to provide an external SATA [eSATA] interface for my RAID of data drives) was incompatible with Leopard and would cause the installer to hang. I finally discovered a firmware upgrade was available that fixed this. This was a stupid rookie mistake. Rule of Thumb: Always check the non-Apple hardware for updates before making a major OS X upgrade.
  • Watch out for /home: I had been using a symbolic link from /home to /Users because in my old Unix days, I hardcoded a lot of my software to look for my home directory in /home. Leopard expects /home to be available as mount point for the automount service, so getting with the modern era and not relying on /home to point to /User is required if you adopt Leopard.
  • Rebuild Web Server Configuration: One problem I was prepared for is that the web server was updated to Apache2. This in itself was not bad, but the configuration files for Apache (version 1) were stored in /etc/httpd and the new configuration files for Apache2 are in /etc/apache2 and they were NOT migrated. I don’t fault Apple for not migrating the files, but I kicked this around on my laptop quite a bit in order to tweak the configuration files back to something I liked. One thing I immediately did was that this MacOS comes with PHP 5.2.4 preinstalled, but not enabled in Apache2. I enabled it by editting the /etc/apache2/httpd.conf file (which you might have to create) and uncommenting the line with # LoadModule php5_module (by removing the ‘#’ symbol from the beginning of the line). Once that was done, I restarted the Apache2 server and all my PHP code (including this blog) was running again.
  • Tweak MySQL for Leopard: The PHP 5.2.4 included with MacOS X is compiled with support for MySQL. This is nice in that you can just download the MySQL package installer and quickly get a LAMP server running. However, it was set up with the MacOS X Server version of MySQL in mind, which means it expects the socket to be in a different location than the vanilla MySQL. This can be solved by either tweaking the MySQL configuration (as outlined in the MySQL section of the blog post at http://remysharp.com/2007/10/27/lamp-in-leopard-osx-105-php5-and-apache-22/ ) or by tweaking the PHP configuration by editing the /etc/php.ini file (if it doesn’t exist, first copy /etc/php.ini.default to /etc/php.ini) and search for the line containing mysqli.default_socket = to read
    mysqli.default_socket = /private/tmp/mysql.sock
    
    This solution seemed more straight forward, so I did this.
  • Reinstall MacPorts: Since I am aficionado of MacPorts, I reinstalled it and rebuilt all the ports. Some of the issues I had before with MacPorts on Leopard on my MacBook Pro cropped up again on my PowerMac G5, notably
    • gv still needs to be patched as I noted here.
    • sqlite3 still does know about its dependence on nawk.
    • xterm doesn’t install unless you update your X11 installation using the latest version of Xquartz (currently at version 2.1.4).
  • Update to latest version of Xquartz: Since I don’t like X11 headaches, I updated to the latest version of Xquartz (currently at version 2.1.4).

So the adventure continues. Back to research, I have invested about 5 hours of my spring break into this upgrade, that is enough for now.

SAOImage DS9 5.1 released 2

Posted on January 14, 2008 by Juan

The folks behind SAOImage DS9 have now released version 5.1. The big change I’ve noticed since the last version is that version 5.1 works without issues under Leopard’s new X11 implementation. Of course, the disadvantage is you now must download a version compatible with your OS version as well as your CPU.

More detailed release notes are available here. See my previous post on SAOImage DS9 5.0 to see how it is possible to upgrade the binaries included with SciSoft OSX.

  • Translate

  • Astro Pic o' the Day

  • Archives

  • Admin



↑ Top