On Apr 28, 2010, at 8:32 AM, Alexander Hansen wrote: > On 4/28/10 12:22 AM, PFudd wrote: >> On Tue, 2010-04-27 at 21:24 -0400, Alexander Hansen wrote: >> >>>> This problem (no suitable image found, due to wrong architecture) also >>>> occurred when trying to compile gd-graph-pm588 a couple of weeks ago, >>>> but we worked around the problem by giving up and using an older >>>> computer running Leopard. >>>> >>> Did you report it? I can't find that in my archives. We aren't >>> mind-readers and don't have a connection to your machine, and so we >>> don't know if a package is broken unless we receive a report. >>> >> The bug tracking system(s) appears to be broken or completely missing: >> > I believe that was a beta which was never publicly advertised. We > should probably have Google remove it from their cache. >> See most of the links on http://bugs.finkproject.org/bugs/ : >> >> http://bugs.finkproject.org/release-critical/ >> http://bugs.finkproject.org/pseudo-packages >> http://bugs.finkproject.org/db/ix/full.html >> http://bugs.finkproject.org/db/ix/packages.html >> http://bugs.finkproject.org/db/ix/maintainers.html >> http://bugs.finkproject.org/cgi-bin/bugreport.cgi?bug=1234 >> http://bugs.finkproject.org/cgi-bin/pkgreport.cgi?which=pkg&data=tcsh&archive=no >> http://bugs.finkproject.org/cgi-bin/pkgindex.cgi?indexon=pkg >> >> The bug tracker on sourceforge had a comment about "Even though we have >> this SourceForge.net bugs tracker it is not really used." The >> highlighted in red link ("Please read this page before submitting a bug >> report.") said to search the web first, as "Search engines are you >> friends." >> >> The customer was getting cranky from waiting, so rather than deal with >> another hoop, we just got on with things. >> > >> This time, while searching the net for a solution, I found someone who >> happened to be having the same error with the same package; it even >> happened to be on a fink-related mailing list. After I found the cause >> of the problem, I thought I'd mention it on the list, as I couldn't find >> this answer elsewhere on the web. >> >> >>> <snip 1-3 as irrelevant to Fink> >>> >> Maybe, but handy to mention for people who are googling, the prime >> source of solutions. >> >> >>>> 4. Install DBI and fail to install DBD::mysql from fink (compile error >>>> seen above by me and Oliver). >>>> >>>> 5. Install mysql from fink despite mysql being installed on system by >>>> Apple. I really don't want to damage the system version. >>>> >>> It shouldn't hurt anything. It's supposed to be able to coexist. >>> >> Maybe. When dealing with this particular bug, I was forced to question >> more and more assumptions. "When you've eliminated everything else, >> what remains must be the truth." >> >> >>> <snip 6-10 as also irrelevant to Fink> >>> >> It helped the story. >> >> >>>> 11. Careful trial and error of: >>>> a. deleting all environment variables from the test CGI script >>>> b. adding back just the essential ones: PATH and PERL5LIB (for the >>>> vendor's packages) >>>> c. trying one variable from the command line environment at a time >>>> until the CGI script can no longer run the command line program >>>> d. finding that VERSIONER_PERL_PREFER_32_BIT=yes is the guilty party >>>> >>>> 12. Looking for VERSIONER_PERL_PREFER_32_BIT in my startup files >>>> and /etc directory tree was fruitless. >>>> >>>> 13. In a moment of clarity, check /sw/etc directory tree: found it! >>>> >>>> 14. unsetenv VERSIONER_PERL_PREFER_32_BIT makes command line programs >>>> work. >>>> >>>> 15. Find someone to tell this to. >>>> >>>> Anyhoo, yes, the problem is that #$%#$ environment variable. It's set >>>> by Fink, and affects non-fink programs started from the command line. >>>> The web server is unaffected, since it doesn't run >>>> the /sw/etc/profile.d/fink.sh file; that server is started from launchd. >>>> >>>> The problem (bad architecture) Oliver had is one of the steps listed >>>> above (#4), and is intimately related to that environment variable. >>>> It's possible that he's installing dbd-mysql-pm5100 in an effort to >>>> solve the same problem I encountered (the system DBD::mysql doesn't >>>> work, gives _mysql_init not found error). The process of uninstalling >>>> and reinstalling things in an effort to get the architecture consistent >>>> was suggested by various articles found via Google, and didn't work. >>>> >>> Again, that's not our problem. >>> >> Quit being so defensive. I didn't say it was your problem. This is the >> first time someone's discovered the root cause of these errors, if the >> lack of any googleable solutions is any guide. >> > What I meant was not _our_ problem was all the stuff you went through > via your Google search. > > VERSIONER_PERL_PREFER_32_BIT was the cause of _your_ error, however, > which involves mixing Fink and non-Fink stuff, which we can't really > predict the results of easily since there are so many possible > permutations. Which is not to say that we don't appreciate the report. > > Oliver's error appears to be solely due to the Fink package description > for dbd-mysql-pm5* not actually having been tested and updated for 10.6, > and has nothing to do with having VERSIONER_PERL_PREFER_32_BIT set. In > fact, my understanding is that that environment variable _has_ to be set > for 32-bit Fink builds against the system's Perl to work--other methods > that were tried just didn't do the job. >> Actually, since setting VERSIONER_PERL_PREFER_32_BIT causes bad >> interactions between the system-provided mysql and system-provided >> DBD::mysql, maybe it is technically a Fink problem. Reinstalling Fink >> in 64-bit mode would unset that variable, wouldn't it? >> > Yeah, it's not set under x86_64. >>>> Does that spell things out enough? >>>> >>> It's clearer now. The original message was a bit too jammed together >>> for me to parse out what exactly was being reported. >>> >>> So there are two issues which are actually within _our_ scope here: >>> >>> 1) make dbd-mysql-pm5100 work--which is probably not too hard, and just >>> requires somebody to take the time to do it. >>> >> >>> 2) determine whether VERSIONER_PERL_PREFER_32_BIT has to be set at >>> runtime for fink to work. That might be more involved. >>> >>> As a workaround, you might try deactivating the ". /sw/bin/init.sh" in >>> your .profile, and run that manually when you need to use Fink stuff or >>> do builds. That way the environment variable won't be set unless it >>> needs to be. >>> >> I use a lot of Fink stuff; switching back and forth isn't going to be >> easy. >> >> > I do sympathize, but since it seems that we need > VERSIONER_PERL_PREFER_32_BIT set for internal consistency for building > within the distro, it's not going to go away unless some other method to > make the system Perl do what we want surfaces.
I just updated dbd-mysql-pm5100 so that it builds on both 10.6/i386 and x86_64. I also updated it to the latest upstream version. I have no idea if it actually works though as I don't use mysql and the self-tests require a working mysql server. Daniel ------------------------------------------------------------------------------ _______________________________________________ Fink-beginners mailing list [email protected] http://news.gmane.org/gmane.os.apple.fink.beginners
