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. ------------------------------------------------------------------------------ _______________________________________________ Fink-beginners mailing list [email protected] http://news.gmane.org/gmane.os.apple.fink.beginners
