Re: [Fink-users] Build failure in icon-9.5.0-2 on Yosemite
> 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. I just committed an update of the icon package to 9.5.1 which should be fixing all the outstanding issues. Thanks for the report. Matthias -- 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
Re: [Fink-users] Build failure in icon-9.5.0-2 on Yosemite
> On Apr 28, 2015, at 19:46, Mark D. McKean wrote: > > On 04/28/2015 09:57 pm, Alexander Hansen wrote: >> 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. > > I guess I don't understand the Darwin implementation well enough. What > makes /usr/local so potentially problematic? I've installed a number of > Unix-based packages outside of any package manager--things that have a > OS X/Darwin-specific installer, such as MacGPG--and they pretty much all > go into /usr/local. > > My current desire to avoid using Homebrew on this system is based more > on the difficulties I've had keeping track of two separate package > managers than on any concerns or issues with where it installs. That, > and I don't care for the lack of local information about their > packages--you have to visit the project's home page to find out even > what a package does in some cases. > >> 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. > > Which makes sense, particularly knowing that you've been burned before. > >> 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. > > Yeah, I admit I was remiss. Okay, I was lazy and tired. I'll try to > avoid skipping that step in the future. > >> So it looks like icon needs a “UseMaxBuildJobs: false” declaration in >> its .info file. > > Another attribute I wouldn't have even guessed existed. I suppose it's > time for me to dig into more specifics about Fink packaging, huh? > Especially since I've found two packages I had installed via Homebrew > before that don't appear to be in Fink yet--they're just games, so it's > not as though they're really important, but this might be a good > opportunity for me to learn how to do this. I'd really like to be able > to help more with this project in general. > > Mark D. McKean > qpa...@quantumpanda.com > > - The big deal with /usr/local is that it’s pretty darn hard to hide from the build tools, so that headers and libraries that live there tend to get picked up automatically. That can be a problem for Fink builds because (1) they aren’t necessarily compatible, and (2) by removing them the relevant Fink package will be broken. -- 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
Re: [Fink-users] Build failure in icon-9.5.0-2 on Yosemite
On 04/28/2015 09:57 pm, Alexander Hansen wrote: > 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. I guess I don't understand the Darwin implementation well enough. What makes /usr/local so potentially problematic? I've installed a number of Unix-based packages outside of any package manager--things that have a OS X/Darwin-specific installer, such as MacGPG--and they pretty much all go into /usr/local. My current desire to avoid using Homebrew on this system is based more on the difficulties I've had keeping track of two separate package managers than on any concerns or issues with where it installs. That, and I don't care for the lack of local information about their packages--you have to visit the project's home page to find out even what a package does in some cases. > 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. Which makes sense, particularly knowing that you've been burned before. > 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. Yeah, I admit I was remiss. Okay, I was lazy and tired. I'll try to avoid skipping that step in the future. > So it looks like icon needs a “UseMaxBuildJobs: false” declaration in > its .info file. Another attribute I wouldn't have even guessed existed. I suppose it's time for me to dig into more specifics about Fink packaging, huh? Especially since I've found two packages I had installed via Homebrew before that don't appear to be in Fink yet--they're just games, so it's not as though they're really important, but this might be a good opportunity for me to learn how to do this. I'd really like to be able to help more with this project in general. Mark D. McKean qpa...@quantumpanda.com -- 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
Re: [Fink-users] Build failure in icon-9.5.0-2 on Yosemite
> On Apr 28, 2015, at 18:38, Mark D. McKean wrote: > > On 04/26/2015 11:58 am, Alexander Hansen wrote: > >>> 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. :-) > > >>> 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. > > >>> 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: > >>> 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/Co
Re: [Fink-users] Build failure in icon-9.5.0-2 on Yosemite
On 04/26/2015 11:58 am, Alexander Hansen wrote: >> 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. :-) >> 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. >> 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: >> 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/ico
Re: [Fink-users] Build failure in icon-9.5.0-2 on Yosemite
> On Apr 23, 2015, at 19:55, Mark D. McKean 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 parti
