+universal help

[Scott Haneda]

Trac of patch file has been posted: 
http://trac.macports.org/ticket/23453

Comments interspersed below...

On Jan 27, 2010, at 5:16 PM, Ryan Schmidt wrote:

> On Jan 27, 2010, at 14:12, Scott Haneda wrote:
> 
>> Hello, I am working on adding +universal to memtester, which is a "configure no" style portfile.
>> 
>> Not using MacPorts, I just figured out how to get this to built out universal.  There are two files in the source
>>   conf-cc
>>   conf-ld
> 
> Yes, sorry, I was going to suggest to you that you modify conf-cc and conf-ld but I hadn't quite gotten everything to work yet.

No problem, in a way I am glad you did not, as I had to trudge through it :)  I looked at those files before, and noticed they had random comments below line #1.  I always wondered how that worked.

I explored the source and saw there are `head -n1` lines that read those two files in, which now makes sense to me.  From there, I figured to check the difference in gcc/cc

    $which cc
      /usr/bin/cc
    $which gcc
      /usr/bin/gcc

Learning those are just links to gcc-4.2

    lrwxr-xr-x   1 root  wheel   7 Jan 22 03:06 /usr/bin/cc -> gcc-4.2
    lrwxr-xr-x   1 root  wheel   7 Jan 22 03:06 /usr/bin/gcc -> gcc-4.2

And I also found:

    -rwxr-xr-x  1 root  wheel   97392 May 18  2009 /usr/bin/gcc-4.0

Not sure why 4.0 is kept around, but at least I know there is that option available just in case some day, it may be needed.

I thought to point this out in case it would be helpful to anyone else in this same "configure no" scenario.

>> If I edit them to this:
>> 
>>   head -n1 conf-cc
>>   /usr/bin/gcc -O2 -DPOSIX -c -arch x86_64 -arch i386
>> 
>>   head -n1 conf-ld
>>   /usr/bin/cc -s -arch x86_64 -arch i386
>> 
>> Previous pre-edit of the files were lacking the full path, and of course, lacking the string "-arch x86_64 -arch i386"
>> 
>> Do I need to add ppc and the rest of the -arch's?  What is the full list I should be adding?
> 
> You need to add the archs the user has requested via the universal_archs variable in macports.conf, accessible in the portfile via the ${configure.universal_archs} variable. MacPorts has already assembled the string with all the arch flags for you. It's in the variable ${configure.universal_cflags}.

Ahhh, ok, I get it.  So ${configure.universal_archs} and ${configure.universal_cflags} are sort of dynamic variables, in that, at install time of MacPorts, they will get set to sane defaults for that architecture/flags.  I need not really think about adding in the arch's, especially not to add in archs for example, for ppc or ppc64, since in my case, I am on Intel.  However, someone on PPC, when they installed, they would have entirely different defaults in macports.conf, and they would inherit those into those variables.

This actually clears up the last bits of confusion I had with my thread the other day on configuring and setting up macports.conf on a new install.

And I am quite please to be able to show:
    $port installed | wc -l
          45

So 44 ports installed (line one does not count) on this new system install.

I am a little confused about:

    $port installed | grep -v 'universal'
    The following ports are currently installed:
      autoconf @2.65_1 (active)
      autoconf213 @2.13_1 (active)
      curl-ca-bundle @7.19.7_1 (active)
      mysql5 @5.1.42_0 (active)
      mysql5-server @5.1.42_0 (active)
      p5-locale-gettext @1.05_2 (active)
      perl5 @5.8.9_0 (active)

I never explicitly installed any of those, (sans Mysql) so they came along with Apache2, or php5, or some other software.  Am I just getting lucky that the universal builds are working with these?  Or is it that as long as those are all the *same* arch, I am fine?

    $file `which mysql5`
      /opt/local/bin/mysql5: Mach-O 64-bit executable x86_64

Is this the relevant reason for MySql not being able to have a universal variant:
  http://bugs.mysql.com/bug.php?id=47360

I also found this ticket:
  http://trac.macports.org/changeset/62287

Since it does not appear there is going to be a timely fix on MySql's part for this, at least, in reading over the bugs.mysql.com thread, would taking the suggestion to use lipo and stuff them together be an option, or does lipo add more build time than is desired, that being the only downside I can estimate.

Just curious, as it does not effect me at this time.

> memtester also doesn't support selecting a different build_arch in macports.conf (portfile variable: ${configure.build_arch}). This is to be expected, since that also happens in a way that assumes a configure-based script; ports that don't use the default universal variant don't by default get build_arch support either. The solution is similar, and the pre-made architecture flag is in the variable ${configure.cc_archflags}.

In regards to the lack of a configure script, why would a developer chose omit it?  How exactly are configure scripts made?  I am assuming that they are not hand coded, but perhaps tuned by hand at some point?  Looking over a few, they look more machine written than hand written.  That being the case, I fail to see why one wold chose to not have a configure step.

>> Just adding those will not get +universal to show up in `port info`, can someone guide me with that part?
> 
> Declare a universal variant.
> 
> variant universal {
> 	...
> }

Yep, got it, thanks!

>> What is the best way to reinplace the data I need to?
>> 
>> Here is what I get after running `make`:
>>   $file memtester
>>   memtester: Mach-O universal binary with 2 architectures
>>   memtester (for architecture x86_64):	Mach-O 64-bit executable x86_64
>>   memtester (for architecture i386):	Mach-O executable i386
>> 
>> My guess would be to add:
>> platform darwin 10 {
>>   # Reinplace foo to alter the above two files
>> }
> 
> This has nothing to do with Snow Leopard specifically so there's no call for a platform darwin 10 section.

Yeah I was sort of stumbling along at this point, using `mtr` and a grep for 'configure no' through all the ports.  I still do not entirely understand the platform "phase"?, but am gathering, it is how you do specific things for specific platforms.  So darwin 10 == 10.6 and darwin 9 == 10.5 etc etc.  If there is ever call for special scenarios just for that OS release, this is where you would do it?

For example, `mtr` needs "configure.env-append LIBS=-lresolv" for 10.6, but apparently does not need it for lesser versioned OS's?  Or I must have this wrong, as `port info mtr` lists "darwin_10" as a variant, implying I can apply that to any version OS I desire.  So yeah, still a little muddled in this area.

>> * If I do add -arch ppc and -arch ppc64, I get a bunch of errors, the main one being:
>>   ld: symbol(s) not found for architecture ppc64
>>   collect2: ld returned 1 exit status
>>   lipo: can't open input file: /var/tmp//ccpg8LXX.out (No such file or directory)
>>   make: *** [memtester] Error 1
>> 
>> I just tried to built the current port on a PPC machine, and I get:
>>   $sudo port install memtester
>>   Password:
>>   Warning: Can't open index file for source: file:///Users/me/macports
>>   Error: Port memtester not found
> 
> Attached is a patch that allows memtester to build universal and for a non-default build_arch. It seems to build fine on Snow Leopard (x86_64 only, i386 only, x86_64/i386 universal) and Leopard on a G4 (ppc only, ppc/i386 universal).

I tested it on:
    $uname -a
    Darwin foo.example.com 9.8.0 Darwin Kernel Version 9.8.0: Wed 
    Jul 15 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Power 
    Macintosh

Which is also a pretty aged PPC machine, humping along on 10.5 somehow.

Thank you for putting in the work of the diff/patch, it was very helpful in my understanding this process.

-- 
Scott * If you contact me off list replace talklists@ with scott@ *