Re: Yet another Mac OSX and DBI question
On Oct 16, 2004, at 5:43 PM, David Jantzen wrote: Note that the XCode upgrade solves other C compilation issues as well. I was seeing compiler cannot create executable messages trying to compile nmap, and I wouldn't be surprised if there were other problems waiting in the wings. It's probably good advice for anyone doing dev work on OSX to upgrade to 1.5. There's one caveat, though: the build of gcc which shipped with XCode 1.5 is known to produce incorrect output from C++ code under certain circumstances. See http://article.gmane.org/gmane.os.apple.fink.beginners/13580/ match=cc1plus+download+costabel for a workaround. -- Dave
5.8.1 differences (was Re: Pantherbites)
[EMAIL PROTECTED] wrote: Sorry for the probably silly question, but just what are the differences between 5.6.1 and 5.8.1? I am 100% ig'nant, but I assume that most/all 5.6.1 scripts will port fairly hands-off? What are some gotchas that us noobs should watch for to make sure our stuff works when we try to run it on Panther? Two things that occur to me right away to watch out for (I'm sure other people will have other comments): 1) There are a large number of perl modules which ship with 5.8.1 but did not ship with 5.6.1. For the most part, this is a good thing, but you'll need to watch the version numbers of the modules if the version number is important to your code. 2) Any XS modules which were compiled against perl 5.6.1 will break. This also applies to any executable or library which you may have which links against the main perl library /System/Library/Perl/darwin/CORE/libperl.dylib HTH, Dave
Re: head vs. head
The head vs. HEAD problem is a well-known problem with using CPAN on Mac OS X. There was some discussion on this list last month because some people believed that the problem had been fixed. Sadly, your experience proves otherwise. Indeed, one can blame this problem on the unique characteristics of the HFS+ filesystem. Wherever the blame lies, however, the fact remains that there are now a huge number of machines with Mac OS X installed using the HFS+ filesystem -- perhaps more than any other flavor of Unix, if Apple's propaganda is to be believed. Case-insensitivity is here and it is widespread, and CPAN should be modified to take it into account IMHO. -- Dave
Re: Perl 5.8 dyld errors with CPAN.pm
Tom Insam [EMAIL PROTECTED], in response to Barry C. Hawkins, wrote: I am experiencing the same trouble after building Perl 5.8.0 from source, following the article on Apple's Developer Connection titled Installing Perl 5.8 on Jaguar http://developer.apple.com/internet/macosx/perl.html. The information on This web page needs more big red warnings on it. known problems published in the perldelta document http://dev.perl.org/perl5/news/2002/07/18/580ann/perldelta.html#mac%20os%20x%20dyld%20undefined%20symbols advises a workaround for this problem, but I achieved the same results after trying their workaround. The Undefined symbols errors persist, and can be seen using CPAN or fink. http://archive.develooper.com/[EMAIL PROTECTED]/msg02447.html As also linked from the apple page, under the link about perldelta. Barry, The archived message which Tom referred you to is now somewhat out of date, as far as Fink is concerned. As of the mid-June Fink release 0.5.3, Fink will now coexist quite happily with Perl 5.8, even a copy of Perl 5.8 which was installed by following the misguided instructions from the Apple Developer Connection. If your Fink installation is older, you'll probably need to follow the instructions in that archived message about moving the Storable module out of the way and then rebuilding. Updating Fink to the latest version should replace any offending fink perl modules with versions that work with 5.6 only and do not interfere with 5.8. In order to do that successfully, you may need to install the fink package for perl5.6.0, or else entirely remove some of your fink-installed perl modules. The underlying problem-- that 5.6 modules are incompatible with 5.8 --remains, however, so if you have non-fink perl modules (installed by CPAN or otherwise) you'll need to find a way to rebuild them. -- Dave
Re: Perl for Panther
Of course, it's not just perl modules which will break during the upgrade. Anything which has linked to /System/Library/Perl/darwin/CORE/libperl.dylib will break. This includes eperl and irssi. -- Dave
Re: Perl for Panther
Folks, Apple has already given us considerable information about Perl in Panther. The release of the source files which correspond to the external opensource parts of the WWDC Panther seed includes the source for the version of perl which is on that seed. See: http://www.opensource.apple.com/darwinsource/7.0b1/index.html And Edward Moy, with the permission of his bosses, made the release notes for Perl in Panther publically available. According to those notes, there will be very little change between the version used in the seed and the final version. -- Dave
Re: Installing 5.8.0
Robin [EMAIL PROTECTED] wrote: [snip] upgrades, it belongs to you. Install perl via CPAN as shown also won't overwrite the perl used by the OSX system itself (perl5.6, kept in Has the problem with CPAN overwriting /usr/bin/head with /usr/bin/HEAD been solved? [snip] know what is on your system because you install it - in the past I used fink, which is actually a series of perl modules and started getting problems after I upgraded perl coming from the modules installed by fink unbeknowst to me. Just FYI, Fink finally plays well with perl 5.8.0 installations. If you upgrade to the latest CVS version, all XS-modules are installed in properly-versioned subdirectories of the perl5 directory, and Fink should run just fine with any version of perl from 5.6.0 through 5.8.x. -- Dave
Re: Perl/Tk on OSX?
There are two separate installations which must be done to get a complete X11.app installation: the main installation and the SDK installation (which is hiding down at the bottom right of Apple's web page). The file /usr/X11R6/include/X11/Xlib.h is installed by the SDK part. -- Dave
Re: magic bullet needed for Perl upgrades on Mac OS X
I can't resist chiming in to this discussion. The problem of how to have multiple versions of Perl coexist on a system was solved in Perl long ago. It involves storing certain things in directories labeled with the version number, and specifying those directories at compile-time so that they are encoded in the perl binary. This way, no matter which binary you might have symlinked to /usr/bin/perl, it will look in the correct place and find modules which are appropriate for it. Not only can versions easily coexist, but upgrades are relatively painless. Unfortunately, this aspect of compiling Perl was ignored by Apple when they first imported Perl to their system, and there is no versioning in their directory setup. Can this be fixed? Sure, about a dozen ways, and I imagine Apple is going to fix it when they give us perl5.8.0 . In fact, a fix was proposed last October by Fred Sanchez, former lead of the BSD group at Apple, and accepted into the perl sources: http://archive.develooper.com/[EMAIL PROTECTED]/msg06039.html A message on the perl5-porters list at the time indicated that Fred also planned to explain to Apple how they can implement this while maintaining backward-compatibility: http://archive.develooper.com/[EMAIL PROTECTED]/msg87083.html -- Dave
Re: Fink sets PERL5LIB
On Feb 13,2003 09:00:03 -0700, Nathan Torkington [EMAIL PROTECTED] wrote :
David R. Morrison writes:
The problem here is that Fink compiled Storable.pm under /usr/bin/perl,
which for most people would be the Apple-installed 5.6.0 version, and you
are now running a different perl version.
The trouble is that Apple (in their infinite wisdom and glory) have
removed the version number from the Perl library paths. This is what
would let multiple versions of Perl coexist in peace.
So perhaps you should put the version number into Fink's Perl library
and change init.csh to do something like:
PERL_VERSION=`perl -MConfig -e 'print $Config{version}'`
PERL5LIB=/sw/lib/perl5/$PERL_VERSION
Starting scripts with #!/usr/bin/perl5.6.0 will ensure the system
Perl is used.
Nat
Another strategy I thought of is to ask everybody who compiles their own
version of perl to do it right and to put the version number into the
library path. In fact, Fred Sanchez submitted a patch for the darwin
configuration on perl, which I believe was accepted by the perl project, which
does exactly that. (I'll rummage around and see if I can find that.)
What I'm hoping is that this patch tells perl to look in
$PERL5LIB/$PERL_VERSION. If so, then the only unversioned stuff would be
stock Apple 5.6.0 (in principle), right?
-- Dave
Re: Try out a fink package for 5.6.1?
Ken Williams [EMAIL PROTECTED] wrote: Hi David, Thanks for your feedback! On Monday, February 10, 2003, at 07:17 PM, David R. Morrison wrote: Hi Ken. I've been wanting to get some perl packages into Fink for some time, and this looks like a great start. The package worked well for me, although you do need to adjust where the man files are stored (Fink puts them in /sw/share/man, not /sw/man); Okay, I'll try to adjust that in the .info file. The perl installation location variables are always so non-fun... Well, if its hard to do with perl installation directly, you can do it in Fink's InstallScript (something like mv %i/man %i/share/man at the very end). [snip] One of the problems with the current situation is that there are those widely-followed instructions for replacing Apple's perl by a more recent version, but doing that breaks tools (like Fink) which may depend on a specific version. So it would be great to have a Fink way to install 5.6.1 and/or 5.8.0. Yeah, there could certainly be a fink package made for 5.8.0 and it would work fine. Users could just adjust a /usr/bin/perl (and/or /sw/bin/perl) symlink to get the different versions, or just use the full paths. I think this means that the version number needs to be part of the package name, though, and not just in the fink 'Version' field. Probably perl5.6 and perl5.8, similar to the fink packages apache and apache2, and the various versions of autoconf? Yes, I agree. In fact, my understanding is that 5.6.0 and 5.6.1 would store files in different directories, right? So I think we actually need to call them perl5.6.1 and perl5.8.0 (in preparation for a later perl5.8.1, for example). I don't see any reason to build perl5.6.0 in Fink. [snip] Anyway, certainly if Fink itself is going to be used to compile some 5.6.1 or 5.8.0 modules, then /sw/lib/perl5/site_perl/ needs to be in @INC (although perhaps only in Fink? by setting it in Fink's /sw/bin/init.(c)sh perhaps?). Hmm - mainly because of my preferences for my own machine, I'd like to keep the targetted location for regular (non-fink) CPAN installs /Library/Perl/ even when using the fink perl-5.6.1. /sw/lib/perl5/site_perl/ would be a good place for fink-installed modules, or 5.8.0 modules, though. I don't understand how this works, I guess. Can the user reset the targetted location, even if the one chosen at compile time was different? There are also interesting issues of whether, when Fink compiles a perl module, it should be doing so under multiple versions of perl. I'd appreciate hearing your thoughts about that as well. I was thinking maybe it should sense what perl versions are installed (by probing for fink packages) and just install for any all installed perls, but I don't think that will actually work - what happens if the user installs perl-5.6.1, then DBI, then perl-5.8.0? DBI for 5.8.0 won't be installed. So that seems to point to using separate fink packages for the perl versions. Yes. Roughly what we need to do is to compile the module so that it will work with all versions of perl known to Fink, and store the results in the appropriately numbered sub-directories of /sw/lib/perl5. Now, I'm a bit over my head here, but my understanding is that lots of perl modules will be fine no matter which version they are compiled under, and copies of them could simply be deposited in the appropriate directories. But for other ones, multiple compiles might be needed? I don't know how one tells the difference between these, though. -- Dave
Re: Try out a fink package for 5.6.1?
On Wed, 15 Jan 2003 Ken Williams [EMAIL PROTECTED] wrote: I've been tweaking a perl package for fink over the past couple of days. Unlike my previous efforts, this one installs as /sw/bin/perl and doesn't overwrite anything Apple installs. Its core libraries are at /sw/lib/perl5/. It also uses /Library/Perl/ as its site_perl, which I figured would be convenient since many people may already have a bunch of stuff installed there. I could also add something like /sw/lib/perl5/site_perl/ to @INC if people wanted it. Hi Ken. I've been wanting to get some perl packages into Fink for some time, and this looks like a great start. The package worked well for me, although you do need to adjust where the man files are stored (Fink puts them in /sw/share/man, not /sw/man); I also noticed a little warning about make test not having been run... One of the problems with the current situation is that there are those widely-followed instructions for replacing Apple's perl by a more recent version, but doing that breaks tools (like Fink) which may depend on a specific version. So it would be great to have a Fink way to install 5.6.1 and/or 5.8.0. I guess the ideal setup would let people mix and match Fink and CPAN installations of perl modules at will, but I'm not sure I understand a good way to do that. I've been reading through some of the archives of this list in an attempt to figure it out. (But I guess I've also been nervous about direct CPAN installs because of the old problem of /usr/bin/head being replaced by /usr/bin/HEAD on our wonderfully case-challenged HFS+ filesystem when CPAN was used to install libwww-perl, but perhaps that problem has been solved by now.) Anyway, certainly if Fink itself is going to be used to compile some 5.6.1 or 5.8.0 modules, then /sw/lib/perl5/site_perl/ needs to be in @INC (although perhaps only in Fink? by setting it in Fink's /sw/bin/init.(c)sh perhaps?). There are also interesting issues of whether, when Fink compiles a perl module, it should be doing so under multiple versions of perl. I'd appreciate hearing your thoughts about that as well. Best regards, Dave Morrison
