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

[Ryan Schmidt-24]

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
DEBUG: Found port in file:///Users/rschmidt/macports/dports/net/whois
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: whois 4.7.33_0 exists in the ports tree
DEBUG: whois 4.7.32_0+universal is installed
DEBUG: whois 4.7.32_0+universal is active
DEBUG: Found port in file:///Users/rschmidt/macports/dports/devel/
gettext
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: gettext 0.17_4 exists in the ports tree
DEBUG: gettext 0.17_4+universal is installed
DEBUG: gettext 0.17_4+universal is active
DEBUG: Found port in file:///Users/rschmidt/macports/dports/textproc/
libiconv
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: libiconv 1.12_2 exists in the ports tree
DEBUG: libiconv 1.12_2+universal is installed
DEBUG: libiconv 1.12_2+universal is active
DEBUG: Found port in file:///Users/rschmidt/macports/dports/devel/gperf
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: gperf 3.0.4_0 exists in the ports tree
DEBUG: gperf 3.0.4_0 is installed
DEBUG: gperf 3.0.4_0 is active
DEBUG: No need to upgrade! gperf 3.0.4_0 >= gperf 3.0.4_0
DEBUG: No need to upgrade! libiconv 1.12_2 >= libiconv 1.12_2
DEBUG: Found port in file:///Users/rschmidt/macports/dports/devel/
ncurses
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: ncurses 5.7_0 exists in the ports tree
DEBUG: ncurses 5.7_0+universal is installed
DEBUG: ncurses 5.7_0+universal is active
DEBUG: Found port in file:///Users/rschmidt/macports/dports/devel/
ncursesw
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: ncursesw 5.7_0 exists in the ports tree
DEBUG: ncursesw 5.7_0+universal is installed
DEBUG: ncursesw 5.7_0+universal is active
DEBUG: No need to upgrade! ncursesw 5.7_0 >= ncursesw 5.7_0
DEBUG: No need to upgrade! ncurses 5.7_0 >= ncurses 5.7_0
DEBUG: Found port in file:///Users/rschmidt/macports/dports/textproc/
expat
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: expat 2.0.1_0 exists in the ports tree
DEBUG: expat 2.0.1_0+universal is installed
DEBUG: expat 2.0.1_0+universal is active
DEBUG: No need to upgrade! expat 2.0.1_0 >= expat 2.0.1_0
DEBUG: No need to upgrade! gettext 0.17_4 >= gettext 0.17_4
DEBUG: variants to install {} universal
DEBUG: available variants are : darwin universal
DEBUG: variant universal is present in whois 4.7.33_0
DEBUG: new portvariants: universal +
DEBUG: Changing to port directory: /Users/rschmidt/macports/dports/
net/whois
DEBUG: setting option os.universal_supported to yes
DEBUG: org.macports.load registered provides 'load', a pre-existing  
procedure. Target override will not be provided
DEBUG: org.macports.distfiles registered provides 'distfiles', a pre-
existing procedure. Target override will not be provided
DEBUG: universal variant already exists, so not adding the default one
DEBUG: Requested variant i386 is not provided by port whois.
DEBUG: Requested variant macosx is not provided by port whois.
DEBUG: Executing variant darwin provides darwin
DEBUG: Executing variant universal provides universal
DEBUG: Found port in file:///Users/rschmidt/macports/dports/devel/
gettext
DEBUG: Changing to port directory: /Users/rschmidt/macports/dports/
devel/gettext
DEBUG: setting option os.universal_supported to yes
DEBUG: org.macports.load registered provides 'load', a pre-existing  
procedure. Target override will not be provided
DEBUG: org.macports.distfiles registered provides 'distfiles', a pre-
existing procedure. Target override will not be provided
DEBUG: Using group file /Users/rschmidt/macports/dports/_resources/
port1.0/group/muniversal-1.0.tcl
DEBUG: universal variant already exists, so not adding the default one
DEBUG: Requested variant darwin is not provided by port gettext.
DEBUG: Requested variant i386 is not provided by port gettext.
DEBUG: Requested variant macosx is not provided by port gettext.
DEBUG: Executing variant universal provides universal
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
$

_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Joshua Root-8]

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
...
> DEBUG: Using group file
> /Users/rschmidt/macports/dports/_resources/port1.0/group/muniversal-1.0.tcl

Your whois Portfile is obviously different to the one in the tree (which
doesn't use muniversal), so it's going to be difficult for anyone else
to debug.

- Josh
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Joshua Root-8]

Joshua Root wrote:

> 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
> ...
>> DEBUG: Using group file
>> /Users/rschmidt/macports/dports/_resources/port1.0/group/muniversal-1.0.tcl
>
> Your whois Portfile is obviously different to the one in the tree (which
> doesn't use muniversal), so it's going to be difficult for anyone else
> to debug.

Urgh, sorry, I misread; it's actually gettext failing. Still, the error
seems to occur in muniversal, and the line number doesn't seem to match
up with the version in the tree.

I can't reproduce the failure on a ppc Tiger machine with Xcode 2.5.

- Josh
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Ryan Schmidt-24]

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.



_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Joshua Root-8]

On 2009-5-14 13:35, Ryan Schmidt wrote:

>
> On Apr 21, 2009, at 08:37, Ryan Schmidt wrote:
>
> 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.

[snip]
>
> 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:

Actually, the option-delete behaviour didn't make much sense, so it was
changed: <http://trac.macports.org/changeset/44901>

- Josh
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Ryan Schmidt-24]

On May 13, 2009, at 22:49, Joshua Root wrote:

> On 2009-5-14 13:35, Ryan Schmidt wrote:
>
>> On Apr 21, 2009, at 08:37, Ryan Schmidt wrote:
>>
>> 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.
> [snip]
>>
>> 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:
>
> Actually, the option-delete behaviour didn't make much sense, so it  
> was
> changed: <http://trac.macports.org/changeset/44901>

Ok, that's good. I wasn't sure if there was a reason for that  
behavior. I guess, if there was, it wasn't important anymore.

This still means that no Intel Tiger users can build universal  
versions of ports that use the muniversal portgroup until MacPorts  
1.8.0 is released, unless this issue is fixed in some other way in  
the muniversal portgroup.

Or we could release 1.8.0 soon, or we could backport this fix to the  
1.7 branch and release a 1.7.2 soon...

_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Ryan Schmidt-24]

On May 13, 2009, at 23:11, Ryan Schmidt wrote:

> This still means that no Intel Tiger users can build universal  
> versions of ports that use the muniversal portgroup until MacPorts  
> 1.8.0 is released, unless this issue is fixed in some other way in  
> the muniversal portgroup.
>
> Or we could release 1.8.0 soon, or we could backport this fix to  
> the 1.7 branch and release a 1.7.2 soon...

It would be nice if Intel Tiger users were able to build universal  
ports again with the muniversal portgroup.

When can we release 1.8.0 so this will be fixed?


_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Joshua Root-8]

On 2009-8-2 04:16, Ryan Schmidt wrote:

> On May 13, 2009, at 23:11, Ryan Schmidt wrote:
>
>> This still means that no Intel Tiger users can build universal
>> versions of ports that use the muniversal portgroup until MacPorts
>> 1.8.0 is released, unless this issue is fixed in some other way in the
>> muniversal portgroup.
>>
>> Or we could release 1.8.0 soon, or we could backport this fix to the
>> 1.7 branch and release a 1.7.2 soon...
>
> It would be nice if Intel Tiger users were able to build universal ports
> again with the muniversal portgroup.
>
> When can we release 1.8.0 so this will be fixed?

The workaround is pretty simple and I thought someone already applied it
to the portgroup. I just did so in r54754.

- Josh
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Ryan Schmidt-24]

On Aug 1, 2009, at 14:26, Joshua Root wrote:

> On 2009-8-2 04:16, Ryan Schmidt wrote:
>
>> It would be nice if Intel Tiger users were able to build universal  
>> ports
>> again with the muniversal portgroup.
>
> The workaround is pretty simple and I thought someone already  
> applied it
> to the portgroup. I just did so in r54754.

Thanks, that works great. Now I wish I had thought of that earlier. :)



_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev