date:20150428

Re: [Fink-users] Build failure in icon-9.5.0-2 on Yosemite

2015-04-28 Thread Mark D. McKean

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)

Re: [Fink-users] Build failure in icon-9.5.0-2 on Yosemite

2015-04-28 Thread Alexander Hansen

On Apr 28, 2015, at 18:38, Mark D. McKean qpa...@quantumpanda.com wrote: