> On Apr 28, 2015, at 18:38, Mark D. McKean <qpa...@quantumpanda.com> wrote:
> 
> On 04/26/2015 11:58 am, Alexander Hansen wrote:
> <snip>
>>> After looking inside xpmP.h, I realized it was trying to find the
>>> X11 includes directly in the default location of /usr/include/X11.
>> 
>> This has ceased to exist on OS X as of 10.8.  /usr/include/X11 was a
>> convenience symlink and the Xquartz developers decided to get rid of
>> it, apparently.
> 
> It must have been removed when Apple dropped support for X11 as part of 
> the OS X install. Maybe Apple requested the XQuartz project not use it? 
> Not important, of course, but I frequently wonder about things that 
> aren't important. :-)
> 
> <snip>
>>> A check for whether those headers are in the right place, and
>>> creating the symlink if not, should probably be added to the patch
>>> file for icon.
>> 
>> Absolutely not.  We DON”T mess around in the system area if we can
>> avoid it.  If you want to use some other packaging system that is
>> willing to screw you over, that’s your business, but we’re not going
>> to do that.
> 
> Whoa, calm down. Did I stumble into a touchy subject? I didn't realize 
> that /usr was considered a verboten "system area" for Fink, since most 
> Unix packages installed outside a package manager have no qualms 
> whatsoever about adding things there. It's not as though I suggested 
> removing or replacing something there.
> 
> As for "some other packaging system" screwing me over, that's an 
> inappropriate assertion that appears to come from an incorrect 
> assumption. No other package manager was responsible for creating that 
> symlink--I created it myself based on the educated guess that a new 
> symlink where there was nothing before wouldn't cause any immediate 
> problems and was unlikely to cause any long-term ones unless an Apple 
> update at some point in the future removed it. I didn't even get the 
> idea from some other installer; as I said, that symlink is not present 
> on my Mavericks drive either, where I had successfully installed 
> Homebrew's icon package.
> 
> I suggested the symlink because it seemed to me to be the simplest and 
> most certain solution. It was also the only way I could test my 
> hypothesis myself, since I don't know enough about how Fink packages are 
> set up to make an appropriate change from that side. I didn't expect 
> resolving that problem to simply uncover a different one that I couldn't 
> resolve, so I figured I could make the change, build the package, and be 
> on my way.
> 
>> From a Fink standpoint, the best thing to do is to make sure that
>> -I/opt/X11/include shows up on the compiler lines.
> 
> With the symlink out of the question, that certainly makes sense. I'm 
> not sure why you couldn't have just said that in the first place, and 
> left out the smackdown.
> 
> <snip>
>>> cc -arch i386  -L/sw/lib -o icont tunix.o tglobals.o util.o
>>> trans.o tcode.o tlex.o lnklist.o tparse.o tsym.o tmem.o tree.o
>>> link.o lglob.o lcode.o llex.o lmem.o lsym.o opcode.o
>>> ../common/long.o ../common/getopt.o ../common/alloc.o
>>> ../common/filepart.o ../common/strtbl.o ../common/ipp.o
>>> ../common/munix.o cc -arch i386  -L/sw/lib -o icont tunix.o
>>> tglobals.o util.o trans.o tcode.o tlex.o lnklist.o tparse.o tsym.o
>>> tmem.o tree.o link.o lglob.o lcode.o llex.o lmem.o lsym.o opcode.o
>>> ../common/long.o ../common/getopt.o ../common/alloc.o
>>> ../common/filepart.o ../common/strtbl.o ../common/ipp.o
>>> ../common/munix.o cp icont ../../bin cp icont ../../bin strip
>>> ../../bin/icont strip ../../bin/icont (cd ../../bin; rm -f icon
>>> icon.exe; ln -s icont icon) (cd ../../bin; rm -f icon icon.exe; ln
>>> -s icont icon) ln: icon: File exists make[1]: *** [icont] Error 1
>>> cd src/runtime;
>>> /Applications/Xcode.app/Contents/Developer/usr/bin/make make: ***
>>> [bin/icont] Error 2 make: *** Waiting for unfinished jobs....
>> 
>> This was the fatal error.  You’re building with multiple jobs and it
>> took a while for the other threads to catch up.
> 
> I figured that was why the build continued. That doesn't tell me what 
> makes this a fatal error.
> 
>> This is one reason why we ask people to try again with a single build
>> job before submitting their error messages.
> 
> I usually do. I didn't this time because I was dealing with multiple 
> errors and trying to figure out what I could fix, and I didn't feel like 
> waiting through yet another compile attempt before I could finish that 
> email. By that time it was already really late. My apologies. I have 
> since retried it with build jobs set to 1.
> 
>>> One other thing I noticed: while investigating the problem, I
>>> noticed that the info file for icon specifies a build configuration
>>> that forces a 32-bit build on a 64-bit system:
> <snip>
>>> The most significant change I noticed was that the error I detailed
>>> above was not present this time, but shortly before that point,
>>> this error appeared:
>>> 
>>> strip ixhdr.hdr error:
>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip:
>>> can't move temporary file:
>>> /sw/src/fink.build/icon-9.5.0-2/icon-v950src/src/icont/ixhdr.hdr.strip
>>> to input file:
>>> /sw/src/fink.build/icon-9.5.0-2/icon-v950src/src/icont/ixhdr.hdr
>>> (No such file or directory) cc  -I/sw/include  -c -o lcode.o
>>> lcode.c make[1]: *** [ixhdr.hdr] Error 1 make: *** [bin/icont]
>>> Error 2 make: *** Waiting for unfinished jobs....
>>> 
>>> Comparing these two errors, I see that both occurred during the
>>> attempt to build icont. That certainly might account for the
>>> failure, but the point where both installs failed doesn't mention
>>> icont at all, so I'm at a loss. I've reached the limits of my
>>> current level of understanding.
> 
> I notice that you left this part in the quoted text, but didn't comment 
> on it. Any thoughts on this? I brought this up because while the build 
> failed at the same point, the specific error text sounds to me like a 
> completely different problem, though the only change between the two 
> install attempts was specifying the 64-bit build instead of the 32-bit one.
> 

Nah, lazy on the cut-n-paste.

>>> I'd like to know if there's a good reason for icon to be built as
>>> 32-bit instead of 64-bit. If there isn't, perhaps that should be
>>> changed if/when the info and patch files are updated with whatever
>>> fix, if any, is found for this problem.
> <snip>
>>> Package manager version: 0.38.4 Distribution version:
>>> selfupdate-rsync Thu Apr 23 18:14:10 2015, 10.10, x86_64 Trees:
>>> local/main stable/main stable/crypto Xcode.app: 6.3 Xcode
>>> command-line tools: 6.3.0.0.1.1428348375 Max. Fink build jobs:  3
> 
> So now, here's the weird part: with build jobs set to 1, it built. I got 
> an error at the same point--though not one that matches either of the 
> errors I got before--but the build still completed. It did not matter 
> whether I built the 32-bit or 64-bit package--I built both, and the 
> result was the same either way, with no difference in the reported error.
> 
> My best guess is that the fact I was running multiple simultaneous build 
> jobs is what caused the build errors, but that's just a stab in the 
> dark. I'm not going to test that hypothesis right now by rebuilding it 
> yet again, but I might in the near future if you think it would provide 
> useful information.
> 
> Otherwise, then, it looks like the only issue needing resolved in this 
> package right now is the X11 includes. I'm still curious about the 
> 32-bit/64-bit difference, but that's a question that doesn't need any 
> immediate resolution.
> 
> Mark D. McKean
> qpa...@quantumpanda.com
> 

The “screw you over” thing was a reference to Homebrew’s use of /usr/local.  
I’ve been burned by 3rd-party stuff in /usr/local enough that it is indeed a 
sore point. 

Fink used to install in /usr/X11R6 back when X11 was essentially impossible to 
build in alternative trees, but yeah, by policy we try to avoid doing anything 
outside of the Fink tree.  It reduces the chance of damaging somebody’s system.

It looks like you encountered the second reason we encourage people to try 
building with only one job—some package build systems aren’t able to use 
multiple threads, and this might be one of those.  They can be hard to detect 
because often things will build on the maintainer’s machine but not on another 
with more cpus.  

So it looks like icon needs a “UseMaxBuildJobs: false” declaration in its .info 
file.

-- 
Alexander Hansen, Ph.D.
Fink User Liaison


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Fink-users mailing list
Fink-users@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.macosx.fink.user
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-users

Reply via email to