MySQL port name confusion

[Scott Haneda]

Thanks for all the info, very interesting.  I am glad this came up, as  
there is a pretty big poop fest over on the twitter dev mailing list  
about their user_id breaking into 64 bit territory.

They return JSON for most of everything, and most devs are using php5,  
which most hosts are building out as 32 bit.  From what I can gather,  
when a 64 bit value comes in as JSON and php gets ahold of it, it will  
convert it to a float, and essentially break things.

The suggested solution is to built php5 as 64 bits.  Many apparently  
can not do this.

How does this factor into MacPorts with php5, and all the php5-*  
modules you can add, with their dependencies?  I am going to wager a  
good deal of those are not able to be built as 64 bit at this time,  
does that mean php5 also can not be built 64 bit as well, or the  
internal core of php5 can, but the modules will happily mix and match?

For what it is worth, I am running 32 bit php, as that is what  
MacPorts built for me on a PPC dual g5, and I will have to deal with  
this issue in a twitter app.  Unless of course it is simple to go 64  
bit php5.

For me, I figure, JSON is just a string anyway, so I can simply  
massage that string a little, and store it in mysql as a 64 bit value,  
which even under a 32 bit build will handle it fine.  I am not aware  
of any direct php modification I would need to do on the JSON output,  
as long as I can store it safely in MySql, I am not seeing much  
problem for my apps.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *

On Sep 26, 2009, at 1:01 PM, Ryan Schmidt wrote:

> On Sep 26, 2009, at 14:24, Scott Haneda wrote:
>
>> Question of curiosity.  Why does MacPorts needs to be able to build  
>> a UB? MacPorts builds on the machine it is intended to use.  I am  
>> not aware of many desiring to copy a binary from one machine to the  
>> other, and that would be a lot of work with all the man pages and  
>> other parts that may come along with the binary.
>
> I agree with you, when universal_archs is ppc i386. This was the  
> default for Mac OS X 10.5.x and earlier. But starting with Snow  
> Leopard the default universal_archs is x86_64 i386 and it is very  
> useful. The default build_arch is also x86_64 on Snow Leopard now.  
> This means we build 64-bit by default, which is good because it's  
> faster and lets you use more memory (for example you can use more  
> than 4GB of memory for your MySQL database server, which is  
> something people might want to do). However, not all ports can build  
> x86_64; some need to be built i386 due to various bugs. But if that  
> software requires MySQL, and you've built mysql5 for x86_64 only,  
> then you can't use MySQL from an i386 program. So you would need to  
> build mysql5 universal for both x86_64 and i386.
>
> Users on Leopard can modify their build_arch and universal_archs in  
> macports.conf if they want 64-bit builds.
>
> Users on Tiger can try to do so as well, but it probably won't work  
> for many ports and so is probably not a good idea.
>
>
>> If the arch specific base will build, while probably not ideal with  
>> regard to a UB, is that not more or less the most desirable case?   
>> The UB would be bloated, and many may run lipo on it to get rid of  
>> the parts they can not, or do not want to have.
>
> It would be silly for a user to request the +universal variant and  
> then use lipo to strip out the nonnative architectures. If the user  
> doesn't want a universal build, the user should not request the  
> +universal variant.
>
>
>> Other than MacPorts ability to make a dmg or installer, what is the  
>> reason behind the UB builds, aside from being really cool to be  
>> able to do, and certainly a target moving forward, but in this  
>> case, would the MySql port not suffice to be able to stand as is?
>
> I will probably update the mysql5 port anyway and just disable its  
> universal variant. Any user complaints about this can then be  
> directed at the MySQL developers with whom the blame lies.
>
>
>> I have never added +universal to a port, and in all the port files  
>> I have looked at, a very small percentage even have that variant.
>
>
> MacPorts base includes a default universal variant which all ports  
> inherit, unless they specifically request not to by using  
> "universal_variant no", by using "use_configure no", by using the  
> muniversal portgroup, or by defining their own universal variant.  
> Some portgroups like xcode and cmake define their own universal  
> variants.