August 2009 - Darwin-dev - lists.apple.com

RE: Mac OS X Snow Leopard and 64-bit applications
by Nathan Herring 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AQHKKHQ12UEioCm6b0iHD1zqP6MAvpC+Z14AgAEdbACAABnmAIAAAWWAgAEvIKA= Thread-topic: Mac OS X Snow Leopard and 64-bit applications Over here in CLR-land, we've got similar issues where there's no nice autoconf mechanism to figure out what'll get built by gcc if you fail to provide an -arch flag. We use this because we differentiate between building the tools we need to complete the rest of the build, and the actual build products. (The former must run on the current system, even if it's not the exact architecture. i.e., for an x86_64 machine, it can be ppc if Rosetta is installed, or i386. The latter must run for the target system, which might have different minimum/maximum OS requirements.) If someone comes up with the canonical way to do this, please advise. -----Original Message----- From: darwin-dev-bounces+nathanh=microsoft.com(a)lists.apple.com [mailto:darwin-dev-bounces+nathanh=microsoft.com@lists.apple.com] On Behalf Of Dmitry Markman Sent: Sunday, August 30, 2009 3:04 PM To: Mo McRoberts Cc: darwin-dev(a)lists.apple.com Subject: Re: Mac OS X Snow Leopard and 64-bit applications that's actually exactly the problem for gcc 4.4.1 because config.guess doesn't guess correctly :-) it returns i386-apple-darwin10.0.0 and configure fails miserably unless I provide host, build and target arguments explicitly as x86_64-apple-darwin10.0.0 On Aug 30, 2009, at 5:59 PM, Mo McRoberts wrote: > On Sun, Aug 30, 2009 at 21:26, Brian > Bechtel<brian.bechtel(a)gmail.com> wrote: > >> Arch and uname -p both return the processor family type, i386. (as >> opposed >> to ppc or arm.) I think the rationale was that too many scripts >> depend upon >> this behavior. > > This actually doesn't make a huge amount of sense: something like > config.guess will return 'i386-apple-darwin10.0.1', despite the fact > that gcc will be (by default) targeting x86_64; anything which relies > on the knowledge that "i386" is by default entirely 32-bit will > therefore break. In contrast, most other x86_64 systems tend to be set > up such that x86_64 is reported as the "system" architecture (where > the kernel architecture is pretty incidental), and so you have a > triplet of, say, x86_64-pc-linux-gnu. > > I'd be curious to know what would break if uname returned the > user-space architecture (as targeted by the system compiler by > default) rather than the kernel architecture. > > M. > > -- > http://nevali.net Dmitry Markman _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/nathanh%40microsoft.com This email sent to nathanh(a)microsoft.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Snow Leopard and 64-bit applications
by Terry Lambert 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Nice sentiment, but none of the alternatives to autoconf+autoconf+(g)libtool have proven themselves to be anything but a massive pain in the rear, tending to be fuelled entirely by the arrogant belief that half the stuff autoconf does is unnecessary, rather than simply unnecessary _on their platform of choice_. More to the point, that doesn't actually -help- any given that it's been a de facto standard for longer than Mac OS X has been publicly released ;) -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Aug 31, 2009, at 10:18 AM, Mo McRoberts <lists(a)ilaven.net> wrote: On Mon, Aug 31, 2009 at 17:54, Terry Lambert<tlambert(a)apple.com> wrote: Maybe people should quit using configure entirely. Just saying... The problem with configure is that it localizes code to a given platform, rather than abstracting the platform differences from the code. It's a constant struggle to keep platform dependencies from creeping into the code. It's also a pain when it comes to building universal binaries, unless you are willing to Lipo together individual binaries into a single image. Add to that the nasty tendency to check for intefaces using the linker instead of <unistd.h> feature test macros, and you have a recipe for failure, even if you ignore the cross-target byte order and other issues that plague the code that depends on it. Frankly, xmkmf should have won; at least it abstracted architecture dependence based on macros, and let you safely cross-build. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Snow Leopard and 64-bit applications
by Andrew Gallatin 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.22 (X11/20090608) On Mon, Aug 31, 2009 at 19:19, Andrew Gallatin<gallatin(a)cs.duke.edu> wrote: If you never intend to support odd platforms, it may not be too evil. But once you go beyond linux or BSD and have no longer have a GNUish envoronment, then it gets ugly fast. I once spent about 2 days trying to get libtool to work on Aix. MacOSX was pretty miserable with libtool back in the early days (2002 or so). It may have improved. It is far easier to simply do the link commands by hand, and substitute the correct link command using autoconf. When something doesn't work, its fairly obvious what's not working, and you don't have to look through hundreds or thousands of lines of poorly documented script code to fix somebody's linux-ism (or bash-ism, which winds up being the same thing). You’re making the fatal assumption that the person writing the build rules is the person attempting to build it. Most of the build problems I’ve had with shlibs would be trivially solved with libtool because the original developer, although writing perfectly portable code, wrote no specific build logic for the platform I was building on. _You_ might support Darwin and Solaris, but plenty of developers have neither the time nor inclination to bother with explicit support (and what happens if I'm building on DragonflyBSD, or Interix, or HP-UX?) Granted, you’re SOL if libtool has only embyronic (or no) support for the platform itself, but then you’re still no worse off than the developer of the software doing the same. The problem is you're *worse* off if the developer of the software relied on libfool, and libtool has no working support for your platform. Hence my "never again" trip to into libtool land to try to get our previous product to build on aix. It was exactly the experience of porting to a new platform that led us to avoid libtool in any future projects. Anytime I ever see anybody using automake I just cringe. I have problems getting even trivial projects to build unless I use the exact same machine and path as the developer who initiated the project. I guess there needs to be an auto-something to make automake portable :) I'd suggest that you (or whoever the developer is) are doing it very *very* wrong :) automake "just works" -if- used properly, and you don't attempt to regenerate all the configure scripts and Makefile.ins using completely different versions of autoconf/automake to the ones the project was designed to use. Bingo! -building- an automake project is literally nothing more than ./configure [opts] && make && {sudo|pfexec|su -c} make install [opts]. it's only if you start changing how it works that you actually need to care that it’s automake, except for the fact that you can rely on, e.g., DESTROOT being honoured during a “make install”, and “make distclean” doing the right thing. That's only if the developer checks in the machine generated makefiles. Many open source projects don't do that. The most recent build disaster I had was with ethtool. It was literally faster to write a Makefile from scratch than figure out what automake was objecting to. Very offtopic.. Let's end it here.. Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Mo McRoberts wrote: This is somewhat off-topic by now, though, but having used autotools This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Snow Leopard and 64-bit applications
by Mo McRoberts 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mon, Aug 31, 2009 at 19:19, Andrew Gallatin<gallatin(a)cs.duke.edu> wrote: > If you never intend to support odd platforms, it may not > be too evil. But once you go beyond linux or BSD and have > no longer have a GNUish envoronment, then it gets ugly fast. > I once spent about 2 days trying to get libtool to work on Aix. > MacOSX was pretty miserable with libtool back in the early > days (2002 or so). It may have improved. > > It is far easier to simply do the link commands by hand, and > substitute the correct link command using autoconf. When > something doesn't work, its fairly obvious what's not working, > and you don't have to look through hundreds or thousands of > lines of poorly documented script code to fix somebody's > linux-ism (or bash-ism, which winds up being the same thing). You’re making the fatal assumption that the person writing the build rules is the person attempting to build it. Most of the build problems I’ve had with shlibs would be trivially solved with libtool because the original developer, although writing perfectly portable code, wrote no specific build logic for the platform I was building on. _You_ might support Darwin and Solaris, but plenty of developers have neither the time nor inclination to bother with explicit support (and what happens if I'm building on DragonflyBSD, or Interix, or HP-UX?) Granted, you’re SOL if libtool has only embyronic (or no) support for the platform itself, but then you’re still no worse off than the developer of the software doing the same. > Anytime I ever see anybody using automake I just cringe. > I have problems getting even trivial projects to build unless > I use the exact same machine and path as the developer who > initiated the project. I guess there needs to be an auto-something > to make automake portable :) I'd suggest that you (or whoever the developer is) are doing it very *very* wrong :) automake "just works" -if- used properly, and you don't attempt to regenerate all the configure scripts and Makefile.ins using completely different versions of autoconf/automake to the ones the project was designed to use. -building- an automake project is literally nothing more than ./configure [opts] && make && {sudo|pfexec|su -c} make install [opts]. it's only if you start changing how it works that you actually need to care that it’s automake, except for the fact that you can rely on, e.g., DESTROOT being honoured during a “make install”, and “make distclean” doing the right thing. This is somewhat off-topic by now, though, but having used autotools for the best part of a decade now (and experienced my fair share of its shortfalls, don’t get me wrong), if your experiences were common, nobody would be able to use it, and lots of widely-used things do, successfully! M. -- http://nevali.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Snow Leopard and 64-bit applications
by Andrew Gallatin 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.22 (X11/20090608) On Mon, Aug 31, 2009 at 18:22, Andrew Gallatin<gallatin(a)cs.duke.edu> wrote: Nice sentiment, but none of the alternatives to autoconf+autoconf+(g)libtool have proven themselves to be anything but OK, then I disagree with you 66%. IMHO, autoconf is a necessary evil, but automake and libtool are just pure evil that do nothing but increase obfuscation and frustration. libtool is the most useful of the lot—dealing with the arcane and entirely propriety requirements for building dynamic libs on every platform (especially accounting for dependencies between libraries properly) is something best left to somebody who has the opportunity to focus on them, rather than the app developer, who inevitably gets it wrong for many platforms. If you never intend to support odd platforms, it may not be too evil. But once you go beyond linux or BSD and have no longer have a GNUish envoronment, then it gets ugly fast. I once spent about 2 days trying to get libtool to work on Aix. MacOSX was pretty miserable with libtool back in the early days (2002 or so). It may have improved. It is far easier to simply do the link commands by hand, and substitute the correct link command using autoconf. When something doesn't work, its fairly obvious what's not working, and you don't have to look through hundreds or thousands of lines of poorly documented script code to fix somebody's linux-ism (or bash-ism, which winds up being the same thing). automake has its uses, too; primarily because it integrates with libtool nicely, but also because it manages dependency tracking transparently, and deals with recursion properly. It’s perhaps overkill for a single-dir utility, but for a large cross-platform project it’s fairly essential. I work on a project that we distribute only source for and runs on any Linux distro for the last 5 years or so, MacOSX 10.3+, Solaris 10+, FreeBSD 5.x +, many different Windows versions and probably a few platforms I'm forgetting. Around 300K LOC in ~70 directories. We wouldn't touch automake or libtool with a 10 foot poll. Anytime I ever see anybody using automake I just cringe. I have problems getting even trivial projects to build unless I use the exact same machine and path as the developer who initiated the project. I guess there needs to be an auto-something to make automake portable :) Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Mo McRoberts wrote: On Mon, Aug 31, 2009 at 18:40, Andrew Gallatin<gallatin(a)cs.duke.edu> wrote: Mo McRoberts wrote: Did you mean automake, rather than the second autoconf? Oh, yes—fingers/brain not appropriately coupled, it’d seem! This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Snow Leopard and 64-bit applications
by Mo McRoberts 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mon, Aug 31, 2009 at 18:40, Andrew Gallatin<gallatin(a)cs.duke.edu> wrote: > Mo McRoberts wrote: >> >> On Mon, Aug 31, 2009 at 18:22, Andrew Gallatin<gallatin(a)cs.duke.edu> >> wrote: >>>> >>>> Nice sentiment, but none of the alternatives to >>>> autoconf+autoconf+(g)libtool have proven themselves to be anything but >>> >>> Did you mean automake, rather than the second autoconf? >> >> Oh, yes—fingers/brain not appropriately coupled, it’d seem! > > OK, then I disagree with you 66%. IMHO, autoconf is a necessary evil, > but automake and libtool are just pure evil that do nothing > but increase obfuscation and frustration. libtool is the most useful of the lot—dealing with the arcane and entirely propriety requirements for building dynamic libs on every platform (especially accounting for dependencies between libraries properly) is something best left to somebody who has the opportunity to focus on them, rather than the app developer, who inevitably gets it wrong for many platforms. automake has its uses, too; primarily because it integrates with libtool nicely, but also because it manages dependency tracking transparently, and deals with recursion properly. It’s perhaps overkill for a single-dir utility, but for a large cross-platform project it’s fairly essential. M. -- http://nevali.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Snow Leopard and 64-bit applications
by Andrew Gallatin 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.22 (X11/20090608) Nice sentiment, but none of the alternatives to autoconf+autoconf+(g)libtool have proven themselves to be anything but OK, then I disagree with you 66%. IMHO, autoconf is a necessary evil, but automake and libtool are just pure evil that do nothing but increase obfuscation and frustration. Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Mo McRoberts wrote: On Mon, Aug 31, 2009 at 18:22, Andrew Gallatin<gallatin(a)cs.duke.edu> wrote: Did you mean automake, rather than the second autoconf? Oh, yes—fingers/brain not appropriately coupled, it’d seem! This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Snow Leopard and 64-bit applications
by Mo McRoberts 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mon, Aug 31, 2009 at 18:22, Andrew Gallatin<gallatin(a)cs.duke.edu> wrote: >> Nice sentiment, but none of the alternatives to >> autoconf+autoconf+(g)libtool have proven themselves to be anything but > > Did you mean automake, rather than the second autoconf? Oh, yes—fingers/brain not appropriately coupled, it’d seem! Cheers, M. -- http://nevali.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Snow Leopard and 64-bit applications
by Andrew Gallatin 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.22 (X11/20090608) Nice sentiment, but none of the alternatives to autoconf+autoconf+(g)libtool have proven themselves to be anything but Did you mean automake, rather than the second autoconf? a massive pain in the rear, tending to be fuelled entirely by the arrogant belief that half the stuff autoconf does is unnecessary, rather than simply unnecessary _on their platform of choice_. More to the point, that doesn't actually -help- any given that it's been a de facto standard for longer than Mac OS X has been publicly released ;) Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Mo McRoberts wrote: On Mon, Aug 31, 2009 at 17:54, Terry Lambert<tlambert(a)apple.com> wrote: Maybe people should quit using configure entirely. Just saying... This email sent to site_archiver(a)lists.apple.com

1 0

Re: Mac OS X Snow Leopard and 64-bit applications
by Mo McRoberts 31 Aug '09

31 Aug '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mon, Aug 31, 2009 at 17:54, Terry Lambert<tlambert(a)apple.com> wrote: > Maybe people should quit using configure entirely. Just saying... Nice sentiment, but none of the alternatives to autoconf+autoconf+(g)libtool have proven themselves to be anything but a massive pain in the rear, tending to be fuelled entirely by the arrogant belief that half the stuff autoconf does is unnecessary, rather than simply unnecessary _on their platform of choice_. More to the point, that doesn't actually -help- any given that it's been a de facto standard for longer than Mac OS X has been publicly released ;) M. -- http://nevali.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0