can't read "configure.universal_ldflags": no such variable

[Ryan Schmidt]

On Apr 21, 2009, at 08:37, Ryan Schmidt wrote:

> I am having trouble upgrading an increasing number of ports (for  
> example whois, glib2, python25). I'm only seeing this problem on  
> one machine, as far as I can tell, which is running Mac OS X  
> 10.4.11 Intel, Xcode 2.5, MacPorts 1.7.1. Any ideas? Is anyone else  
> seeing this?
>
>
> $ port -uxd upgrade whois

[snip]

> DEBUG: can't read "configure.universal_ldflags": no such variable
>     while executing
> "eval configure.ldflags-append   ${configure.universal_ldflags}"
>     (procedure "variant-universal" line 18)
>     invoked from within
> "variant-universal"
>     invoked from within
> "catch "variant-${name}" result"
> Error: Error executing universal: can't read  
> "configure.universal_ldflags": no such variable
> DEBUG: Error evaluating variants
>     while executing
> "error "Error evaluating variants""
>     (procedure "mportopen" line 57)
>     invoked from within
> "mportopen $porturl $options $variations"
>     (procedure "mportdepends" line 66)
>     invoked from within
> "mportdepends $mport $target"
>     (procedure "mportexec" line 23)
>     invoked from within
> "mportexec $workername $upgrade_action"
> Error: Unable to upgrade port: Error evaluating variants
> $


I have continued to experience this problem since I originally  
reported it and have just been dealing with not being able to upgrade  
some of my ports.

I have now figured out the problem, and it looks like it will not  
manifest on PowerPC or Leopard machines, at least not with MacPorts  
1.7.x, which explains why Joshua wasn't able to duplicate it on Tiger  
on PowerPC.

First, consider MacPorts 1.7.1's configure_get_universal_ldflags  
procedure:

http://trac.macports.org/browser/tags/release_1_7_1/base/src/port1.0/ 
portconfigure.tcl#L241

As you can see, the universal_ldflags will always end up containing  
the arch flags. On PowerPC, an additional part is appended. On  
Leopard, a different additional part is appended. The extra Leopard  
part has already been removed from trunk

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

so I think users of trunk would also experience the issue on Leopard,  
if they are not on PowerPC.

The problem lies in these lines of the muniversal portgroup:

http://trac.macports.org/browser/trunk/dports/_resources/port1.0/ 
group/muniversal-1.0.tcl?rev=49951#L91

     foreach arch ${universal_archs} {
         configure.universal_cflags-delete    -arch ${arch}
         configure.universal_cxxflags-delete  -arch ${arch}
         configure.universal_ldflags-delete   -arch ${arch}
     }

On non-PowerPC non-Leopard, this will end up with universal_ldflags  
becoming empty, which will cause it to be unset entirely. Therefore  
an error occurs when we then try to append the now-nonexistent  
universal_ldflags to configure.ldflags below:

     eval configure.args-append      ${configure.universal_args}
     eval configure.cflags-append    ${configure.universal_cflags}
     eval configure.cxxflags-append  ${configure.universal_cxxflags}
     eval configure.objcflags-append ${configure.universal_cflags}
     eval configure.ldflags-append   ${configure.universal_ldflags}
     eval configure.cppflags-append  ${configure.universal_cppflags}

This change is the one that caused the problem:

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

If I revert that, things work again.