headers
Jeremy Lavergne | 3 Dec 2010 06:01

Arch of .mo Files

I have a package that is on the path of being noarch, but `file` claims that the produced .mo files are a
specific endian. Are .mo files architecture-specific?

Example, which is attached:
/opt/local/share/locale/fr/LC_MESSAGES/plasma_applet_incomingmsg.mo: GNU message catalog
(little endian), revision 0, 17 messages
Attachment (plasma_applet_incomingmsg.mo): application/octet-stream, 1704 bytes
Permalink | Reply | 4 comments |
headers
Jeremy Lavergne | 3 Dec 2010 06:38

Re: [74050] trunk/dports

> Increased revision number to link against the new library. (icu 4.6)
> ...
> 	• trunk/dports/devel/boost/Portfile

And everyone cried.
Permalink | Reply | 1 comment |
headers
Takanori Yamamoto | 3 Dec 2010 07:10
Favicon

Re: [74050] trunk/dports

If you have any better ways let me know.

On 2010/12/03, at 14:38, Jeremy Lavergne wrote:

>> Increased revision number to link against the new library. (icu 4.6)
>> ...
>> 	• trunk/dports/devel/boost/Portfile
> 
> And everyone cried.
> 
> _______________________________________________
> macports-dev mailing list
> macports-dev@...
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Permalink | Reply | 0 comments |
headers
Ryan Schmidt | 3 Dec 2010 13:34
Favicon

Re: Arch of .mo Files


On Dec 2, 2010, at 23:01, Jeremy Lavergne wrote:

> I have a package that is on the path of being noarch, but `file` claims that the produced .mo files are a
specific endian. Are .mo files architecture-specific?

.mo files are machine-specific (that's what the "m" in ".mo" stands for). So I don't know what that means for
MacPorts arch indication. If we're keeping an eye toward eventual binary distribution, I guess this
means we would need separate .mo files for big- and little-endian machines. But that doesn't fit neatly
into MacPorts supported_arch setting.
Permalink | Reply | 3 comments |
headers
Landon J Fuller | 3 Dec 2010 16:43
Favicon

arch checking?

Hey All --

I ran across this trying to get openjdk6 ported to 10.5/ppc:
	Error: Cannot install openjdk6 for the arch(s) 'powerpc' because
	Error: its dependency apache-ant does not build for the required arch(s) by default
	Error: and does not have a universal variant. 

The apache-ant port is written in Java, has no architecture-specific dependencies, and will build on any
architecture. If I actually try to build+install it, it works fine:
	---> Staging apache-ant into destroot
	---> Installing apache-ant  <at> 1.8.1_0
	---> Activating apache-ant  <at> 1.8.1_0
	---> Cleaning apache-ant 

How should I work around this constraint? It seems a bit odd that the ports system is pre-emptively blocking
me from trying to build something that will work just fine, rather than providing a setting that allows the
few ports that *are* architecture specific to declare themselves as such -- but maybe I'm
misunderstanding what this feature does.

-landonf
Permalink | Reply | 2 comments |
headers
Ryan Schmidt | 3 Dec 2010 17:45
Favicon

Re: arch checking?


On Dec 3, 2010, at 09:43, Landon J Fuller wrote:

> I ran across this trying to get openjdk6 ported to 10.5/ppc:
> 	Error: Cannot install openjdk6 for the arch(s) 'powerpc' because
> 	Error: its dependency apache-ant does not build for the required arch(s) by default
> 	Error: and does not have a universal variant. 
> 
> The apache-ant port is written in Java, has no architecture-specific dependencies, and will build on any
architecture. If I actually try to build+install it, it works fine:
> 	---> Staging apache-ant into destroot
> 	---> Installing apache-ant  <at> 1.8.1_0
> 	---> Activating apache-ant  <at> 1.8.1_0
> 	---> Cleaning apache-ant 
> 
> How should I work around this constraint? It seems a bit odd that the ports system is pre-emptively
blocking me from trying to build something that will work just fine, rather than providing a setting that
allows the few ports that *are* architecture specific to declare themselves as such -- but maybe I'm
misunderstanding what this feature does.

Ports like apache-ant that install no architecture-specific files should so indicate by using the key
"supported_archs noarch".

I've fixed this for apache-ant just now:

http://trac.macports.org/changeset/74060

The vast majority of ports do install architecture-specific (i.e. compiled) files so it makes more sense
to require the few architecture-agnostic ports to be modified.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ryan Schmidt | 3 Dec 2010 17:47
Favicon

Re: Arch of .mo Files

On Dec 3, 2010, at 06:34, Ryan Schmidt wrote:

> On Dec 2, 2010, at 23:01, Jeremy Lavergne wrote:
> 
>> I have a package that is on the path of being noarch, but `file` claims that the produced .mo files are a
specific endian. Are .mo files architecture-specific?
> 
> .mo files are machine-specific (that's what the "m" in ".mo" stands for). So I don't know what that means
for MacPorts arch indication. If we're keeping an eye toward eventual binary distribution, I guess this
means we would need separate .mo files for big- and little-endian machines. But that doesn't fit neatly
into MacPorts supported_arch setting.

I would really hate it if a port had to be considered architecture-specific, for the sole reason that it uses
a gettext message catalog. Perhaps it's like TIFF files: there are big- and little-endian TIFF formats,
but libtiff can read either format regardless what endianness it's running on. Can someone please test
whether a message catalog compiled on a Mac of one endianness works on a Mac of the other endianness?
Permalink | Reply | 0 comments |
headers
Joshua Root | 3 Dec 2010 20:01
Favicon

Re: arch checking?

On 2010-12-4 02:43 , Landon J Fuller wrote:
> Hey All --
> 
> I ran across this trying to get openjdk6 ported to 10.5/ppc:
> 	Error: Cannot install openjdk6 for the arch(s) 'powerpc' because
> 	Error: its dependency apache-ant does not build for the required arch(s) by default
> 	Error: and does not have a universal variant. 

'powerpc' isn't going to work as a supported_archs / build_arch /
universal_archs value; you have to use something that gcc's -arch will
accept (like 'ppc' in this case).

The macports.conf.default shipped in the 10.4 and 10.5 pkgs for a couple
of versions prior to 1.9.2 accidentally had 'powerpc' in the
commented-out build_arch line.

- Josh
Permalink | Reply | 0 comments |
headers
Rainer Müller | 4 Dec 2010 14:19
Favicon

Re: Arch of .mo Files

On 2010-12-03 13:34 , Ryan Schmidt wrote:
> 
> On Dec 2, 2010, at 23:01, Jeremy Lavergne wrote:
> 
>> I have a package that is on the path of being noarch, but `file` claims that the produced .mo files are a
specific endian. Are .mo files architecture-specific?
> 
> .mo files are machine-specific (that's what the "m" in ".mo" stands for). So I don't know what that means
for MacPorts arch indication. If we're keeping an eye toward eventual binary distribution, I guess this
means we would need separate .mo files for big- and little-endian machines. But that doesn't fit neatly
into MacPorts supported_arch setting.

Here is a link to a discussion on this topic on the Debian mailing list.
It might shed some light on this issue.

http://lists.debian.org/debian-devel/2009/01/msg00452.html

Rainer
Permalink | Reply | 1 comment |
headers
Ryan Schmidt | 4 Dec 2010 19:01
Favicon

Re: Arch of .mo Files


On Dec 4, 2010, at 07:19, Rainer Müller wrote:

> Here is a link to a discussion on this topic on the Debian mailing list.
> It might shed some light on this issue.
> 
> http://lists.debian.org/debian-devel/2009/01/msg00452.html

Ok, so that says it will work on the non-native endianness, just a little more slowly. I can live with that.
Permalink | Reply | 0 comments |

Gmane