On Jan 22, 2010, at 4:59 PM, Ryan Schmidt wrote:
> On Jan 22, 2010, at 18:20, Scott Haneda wrote:
>
>> For reasons that are too silly to repeat, I am now sitting on a clean 10.6
>> updated install, with a new MacPorts, and zero ports installed. I will be
>> installing all my ports new and clean.
>>
>> In macports.conf I see:
>> # CPU architecture to compile for. Defaults to i386 or ppc on Mac OS X 10.5
>> # and earlier, depending on the CPU type detected at runtime. On Mac OS X
>> 10.6
>> # the default is x86_64 if the CPU supports it, i386 otherwise.
>> #build_arch i386
>>
>> And also:
>> # Options for Universal Binaries (+universal variant)
>>
>> # machine architectures
>> universal_archs x86_64 i386
>>
>> This is a MacBook that I use for development, 1.83 Intel Core 2 Duo
>>
>> I am thinking I want to build UB for everything. This just seems better in
>> the long run. I will run into the problems of some ports not being able to
>> support it, and can work to solve those problems, or file tickets to get
>> them solved. Is this a good or bad idea?
>
> I personally do this (x86_64 i386 universal) since I must in order to build
> wine. But as you say some ports will not build this way at this time, so
> watch out and be prepared to retry without universal. (sudo port clean
> problemport && sudo port install problemport -universal)
I am still not understanding this. I add multiple values to build_arch and
uncomment it?
#build_arch i386
-- would become --
build_arch x86_64 i386
Arent those both intel specific architectures? I was under the impression a
Universal Binary was a 4 way thing, and would support PPC as well, so some
portion, if not all of this list:
386 ppc ppc64 ppc7400 ppc970 x86_64
Or is it just going to be impossible to expect to build for PPC as well on an
Intel machine? I suppose I do not even want to, as it is just bloat?
I just ran `file` on some of the more popular binaries that Apple ships, and I
find all of them are three way, take httpd for example:
$file /usr/sbin/httpd
/usr/sbin/httpd: Mach-O universal binary with 3 architectures
/usr/sbin/httpd (for architecture x86_64): Mach-O 64-bit executable x86_64
/usr/sbin/httpd (for architecture i386): Mach-O executable i386
/usr/sbin/httpd (for architecture ppc7400): Mach-O executable ppc
So ppc and ppc64 are missing. I am only asking as I am in a position to start
clean. If I make a poor decision now, I will have to go back and rebuild all
my ports, which is risky for some. `mtr` is not something I am worried about,
but some of the more complex chain dependent ones where my own personal files
become part of the install, I worry about just firing off even a `upgrade`
command, let alone something that will run the entire install list and just
upgrade them to a new arch.
You mentioned you used "x86_64 i386 universal", I am assuming that is the value
you have for "universal_archs"? Can you explain that some? As "universal"
seems a keyword, not a real architecture of any form.
>> Would I just delete the i386 string from the "universal_archs"?
>
> No... that would leave your universal_archs with just "x86_64", and a single
> architecture kind of by definition wouldn't be universal. You would leave
> universal_archs as it is and build your ports with the +universal variant so
> they are built for x86_64 and i386.
Got it. But why then, do those ports that support the +universal at best seem
to be building out a 2 way file, at most three? There is an entire line of PPC
arch's that I am not seeing mentioned, and not understanding.
>> I add +universal to most oft the ports I installed in the past, which
>> sometimes got me into trouble, as for example, with php5-mcrypt, I had to
>> also rebuild the entire chain that it was dependent on.
>>
>> Where do I define that I need not remember to add +universal, and it will be
>> the default, and is that even a good idea?
>
> variants.conf. I do this, as indicated above.
At the bottom of variants.conf I added:
+universal
I assume that is the same as appending +universal to a `port install` command.
And if something does not work, or I `port info` a port and notice there is no
universal variant, I simply -universal and it will over-ride it?
I just ran:
$sudo port -d install memtester
$port installed
The following ports are currently installed:
memtester @4.1.2_0 (active)
$file /opt/local/bin/memtester
/opt/local/bin/memtester: Mach-O 64-bit executable x86_64
But I had +universal set in variants.conf, I thought this would stop it in it's
tracks, and force me to make a decision as to what I need to do at that point.
How would I know this port needs altering for fixing, if it just went in clean?
Or I guess this is unique, and has to do with:
DEBUG: not using configure, so not adding the default universal variant
If this was using configure, then I would have been stopped?
>> Looking for suggestions on the pros and cons. I am also fine with just
>> leaving things are they are, but it is my understanding that means my builds
>> are only good for this machine or very similar machines.
>
> I would say MacPorts builds are always only good for this machine or very
> similar machines. Certainly the major OS version (10.4, 10.5, 10.6) and CPU
> architecture (ppc, ppc64, i386, x86_64) must match.
How come? Why could I not built out mcrypt.so for all 4 of those
architectures, and have a .so extension I could share with others if I desired?
I am asking this from a technical perspective, not that there is any desire to
do such a thing. Though in thought, it may be nice, one could make a fully
portable MAMP stack, use Apples Package Maker, or the inbuilt stuff in
MacPorts, put the bits where the need to go, and you should have a MAMP system
up and running on any machine from a old G3 imac forward. Or am I reading into
this all wrong?
>> I am still at a loss, for example, with my memteter Portfile, which does not
>> have a +universal variant. What would happen under an install of that port,
>> where I add +univeral? I assume it will just ignore that and build it for
>> this architecture.
>
> memtester has no universal variant because it sets "use_configure no".
> Therefore it will build for build_arch.
I only did so because that is how the README for the source got me thinking:
memtester is currently only distributed in source-code form. Building
it, however, is simple -- just type `make`. There's no `configure` script
or anything like that.
But it also states:
If you have a really strange system/toolchain, you might need to edit the
conf-cc or conf-ld files, but try to build it without changes first.
I do not really know what to put into those files, or if I should skip that
method and use some form of configure appending. However, since the source
does not use configure, I guess I have to go the road of editing the conf-cc
and conf-ld files.
I will do what I can to learn more about this stuff, this is really not my area
of expertise though. Any pointers are appreciated.
>> But then I look at `port info mtr` and see it has:
>> Variants: darwin_10, universal
>>
>> But looking at the Portfile, these are the only things I see different to me:
>> configure.args-append --without-gtk
>>
>> platform darwin 10 {
>> configure.env-append LIBS=-lresolv
>> }
>>
>> Is that all I have to do, is add in some appended args and will get
>> universal? I suspect I need to go back to the source, and read through it
>> and see what it takes to build memtester out universal, but I am still at a
>> loss as to what is generating the "Variants: darwin_10, universal" line.
>
> mtr has a universal variant because it does not contain the lines
> "use_configure no" or "universal_variant no" and therefore inherits the
> default universal variant defined in MacPorts base which works for most
> autoconf-based software.
>
> mtr has a darwin_10 variant because it contains a section "platform darwin
> 10".
>
> To create a universal variant for ports that aren't standard and can't use
> MacPorts' built-in universal variant, simply define one:
>
> variant universal {
> [do whatever's necessary to build universal]
> }
Ok, so that is the tricky bit I am going to need to figure out with memtester,
thanks.
> It may be instructive to grep existing portfiles for "variant universal" to
> see what they do.
I just did that, there is a lot of stuff in there to go through, thanks for the
suggestion. Hopefully I find one with use_configure set to no, and also still
showing "variant universal". I *think* that will get me closest to the changes
I need to make in the memtester Portfile.
Thank you again for all your help.
--
Scott * If you contact me off list replace talklists@ with scott@ *
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
