> On Apr 23, 2015, at 19:55, Mark D. McKean <qpa...@quantumpanda.com> wrote:
> 
> I have notes in my personal install history journal indicating that I 
> had tried to install the icon package years previously, likely in 2013, 
> and it had failed to compile. I apparently did not submit a report on it 
> because I had found a Homebrew package for it which installed properly.
> 
> Now, I am setting up my system anew after a fresh install of Yosemite 
> (currently 10.10.3), and I'd like to avoid having both fink and Homebrew 
> installed simultaneously. Since I didn't submit a report on the failure 
> before, I have no idea if the current build failure is from the same 
> issue or not. I didn't save the output to my journal, only the fact that 
> the build failed and that I was able to install it under Homebrew.
> 
> I am more knowledgeable now than I was then, so I was able to do some 
> detective work of my own before submitting a report.
> 
> The first time the build failed, the error given was:
> 
>       ./xpmP.h:26:10: fatal error: 'X11/Xlib.h' file not found
> 
> 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.

> However, 
> those include files are actually in /opt/X11/include/X11. There is a 
> symlink at /usr/X11 to /opt/X11, but that doesn't help.
> 
> I created a new symlink:
> 
>       Thu 2015-04-23 09:27:08 PM qpanda in ~ -bash 4.3.33
>       $ sudo ln -s /opt/X11/include/X11 /usr/include/
> 

> When I ran the install again, it did not give that same error message. I 
> checked the clone of my old Mavericks install that I had made before the 
> Yosemite upgrade, and it looks like the same problem would happen on 
> Mavericks, so I'd wager that was what stopped the install the last time. 
> 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.

From a Fink standpoint, the best thing to do is to make sure that 
-I/opt/X11/include shows up on the compiler lines.


> Unfortunately, while that problem was resolved, the install failed 
> again, at a different point. This time, I have no idea what the problem 
> is, because there is no line in the compiler output that I can identify 
> as actually stating a fatal error. The closest I found was in the middle 
> of the output:
> 
>       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....
> 
> But the build continues well past this point, so I don't know if this is 
> ultimately what caused the failure, or if it even has anything to do 
> with the failure at all. I have included the full compiler output after 
> my signature.

This was the fatal error.  You’re building with multiple jobs and it took a 
while for the other threads to catch up.  

This is one reason why we ask people to try again with a single build job 
before submitting their error messages.

> 
> 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:
> 
>       make X-Configure name=mac386
> 
> According to the config notes in the actual source, this is not 
> recommended unless necessary. The patch file doesn't appear to me to 
> change this specification. I tried changing the info file to specify the 
> 64-bit build:
> 
>       make X-Configure name=macintosh
> 
> That changed the output somewhat, but it still failed at the exact same 
> point, so I don't think that helped this particular problem. 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'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.
> 
> At any rate, I hope someone more knowledgeable than me can find the 
> error in this output. Thanks.
> 
> Mark D. McKean
> qpa...@quantumpanda.com
> 

<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


------------------------------------------------------------------------------
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