error installing cogito

[Peter Eddy]

Hello, I ran into the error below trying to install git and cogito. My
ports installation was a mess, so I deleted it and started again with
a fresh install. Same problem. Any ideas?

thanks,
Peter

--->  Fetching cogito
--->  Attempting to fetch cogito-0.18.2.tar.bz2 from
http://kernel.org/pub/software/scm/cogito/
--->  Verifying checksum(s) for cogito
--->  Extracting cogito
--->  Applying patches to cogito
--->  Configuring cogito
--->  Building cogito with target all
--->  Staging cogito into destroot
Error: Target org.macports.destroot returned: shell command " cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_cogito/work/cogito-0.18.2"
&& gnumake install prefix=/opt/local
DESTDIR=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_cogito/work/destroot
" returned error 2
Command output: m755 -d
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_cogito/work/destroot/opt/local/bin
gnumake: m755: Command not found
gnumake: [install-cogito] Error 127 (ignored)
cg-object-id cg-add cg-admin-lsobj cg-admin-uncommit cg-branch-add
cg-branch-ls cg-reset cg-clone cg-commit cg-diff cg-export cg-help
cg-init cg-log cg-merge cg-mkpatch cg-patch cg-fetch cg-restore cg-rm
cg-seek cg-status cg-tag cg-tag-ls cg-update cg cg-admin-ls cg-push
cg-branch-chg cg-admin-cat cg-clean cg-admin-setuprepo cg-switch cg-mv
cg-admin-rewritehist cg-tag-show cg-version
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_cogito/work/destroot/opt/local/bin
gnumake: cg-object-id: Command not found
gnumake: *** [install-cogito] Error 127

Error: Status 1 encountered during processing.
_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[Ryan Schmidt-24]

On Apr 20, 2008, at 7:24 AM, Peter Eddy wrote:

> Hello, I ran into the error below trying to install git and cogito. My
> ports installation was a mess, so I deleted it and started again with
> a fresh install. Same problem. Any ideas?
>
> thanks,
> Peter
>
> --->  Fetching cogito
> --->  Attempting to fetch cogito-0.18.2.tar.bz2 from
> http://kernel.org/pub/software/scm/cogito/
> --->  Verifying checksum(s) for cogito
> --->  Extracting cogito
> --->  Applying patches to cogito
> --->  Configuring cogito
> --->  Building cogito with target all
> --->  Staging cogito into destroot
> Error: Target org.macports.destroot returned: shell command " cd
> "/opt/local/var/macports/build/
> _opt_local_var_macports_sources_rsync.macports.org_release_ports_devel
> _cogito/work/cogito-0.18.2"
> && gnumake install prefix=/opt/local
> DESTDIR=/opt/local/var/macports/build/
> _opt_local_var_macports_sources_rsync.macports.org_release_ports_devel
> _cogito/work/destroot
> " returned error 2
> Command output: m755 -d
> /opt/local/var/macports/build/
> _opt_local_var_macports_sources_rsync.macports.org_release_ports_devel
> _cogito/work/destroot/opt/local/bin
> gnumake: m755: Command not found

[snip]

Are you on Leopard? If so, can you please just try running "sudo port  
install cogito" (or whatever command you executed) again?

The cogito makefile is trying to do this:

$(INSTALL) -m755 -d $(DESTDIR)$(bindir)

In your case, "$(INSTALL)" seems to be empty and so it's trying to  
take the next word ("m755") as a command name, which it isn't. (Why  
the "-" before "m755" is missing I don't know.) This (various  
software packages not finding the programs they need to compile) has  
happened to many Leopard users for reasons we don't understand, and  
just trying it a second time has always resolved it so far.

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

[Guido Soranzio]

On Apr 20, 2008, at 10:28 PM, Ryan Schmidt wrote:

> This (various software packages not finding the programs they need  
> to compile) has happened to many Leopard users for reasons we don't  
> understand.


All these errors are due to the fact that in Leopard sudo doesn't
perserve environment variables.


-Guido
_______________________________________________
macports-users mailing list
macports-users@...
http://lists.macosforge.org/mailman/listinfo/macports-users

[Ryan Schmidt-24]

On Apr 20, 2008, at 3:42 PM, Guido Soranzio wrote:

> On Apr 20, 2008, at 10:28 PM, Ryan Schmidt wrote:
>
>> This (various software packages not finding the programs they need  
>> to compile) has happened to many Leopard users for reasons we  
>> don't understand.
>
> All these errors are due to the fact that in Leopard sudo doesn't
> perserve environment variables.

But do you know why it then works the second time, or how we could  
fix it for our portfiles permanently?


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

[Bryan Blackburn-4]

On Apr 20, 2008, at 3:28 PM, Ryan Schmidt wrote:

>
> On Apr 20, 2008, at 3:42 PM, Guido Soranzio wrote:
>
>> On Apr 20, 2008, at 10:28 PM, Ryan Schmidt wrote:
>>
>>> This (various software packages not finding the programs they need  
>>> to compile) has happened to many Leopard users for reasons we  
>>> don't understand.
>>
>> All these errors are due to the fact that in Leopard sudo doesn't
>> perserve environment variables.
>
> But do you know why it then works the second time, or how we could  
> fix it for our portfiles permanently?
>

Actually, it has something to do with the way the environment is setup  
and cleaned between stages within MacPorts.  I've been trying to  
figure out whether this is a tcl bug, or something specific to the Mac  
OS X install of 8.4.7 (as of 10.5.2), since I can't make it happen  
with 8.5.2.

The basic issue is best demonstrated with a bit of code (first with  
the Mac-default 8.4.7):

% puts $env(CC)
can't read "env(CC)": no such variable
% set env(CC) "gcc"
gcc
% puts $env(CC)
gcc
% array unset env *
% puts $env(CC)

% puts [array get env]
... CC {} ...

Note how CC in the environment is now blank, but still exists, after  
the 'array unset env *' (and if you run this yourself, you'll see all  
the environment variables in that last command are {}).  What it  
should do, and did (I believe) on 10.4 and does with 8.5.2:

% puts $env(CC)
can't read "env(CC)": no such variable
% set env(CC) "gcc"
gcc
% puts $env(CC)
gcc
% array unset env *
% puts $env(CC)
can't read "env(CC)": no such variable
% puts [array get env]

Here, after 'array unset env *' CC is no longer set in the  
environment.  Which is how it should work.  Note also, the last  
command doesn't show all env vars as empty but nothing there.

We can't use 'array unset env' as that is documented to disconnect Tcl  
from the environment, and some messing around hasn't shown a clean way  
to work around this.  Maybe a Tcl expert is needed, and determining if  
this is Mac-specific or 8.4.7; of course, either way, we have to deal  
with it.

FYI, this is done in portutil.tcl (base/src/port1.0/) in proc  
command_exec.

Bryan


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

[Ryan Schmidt-24]

On Apr 20, 2008, at 7:09 PM, Bryan Blackburn wrote:

[about the Leopard problem where some ports fail to install properly  
with a seemingly endless variety of bizarre error messages if  
installing them causes a dependency to be installed first, but the  
port succeeds if you try the install a second time (because now it  
has no dependencies to install)]

> Actually, it has something to do with the way the environment is  
> setup and cleaned between stages within MacPorts.  I've been trying  
> to figure out whether this is a tcl bug, or something specific to  
> the Mac OS X install of 8.4.7 (as of 10.5.2), since I can't make it  
> happen with 8.5.2.
>
> The basic issue is best demonstrated with a bit of code (first with  
> the Mac-default 8.4.7):
>
> % puts $env(CC)
> can't read "env(CC)": no such variable
> % set env(CC) "gcc"
> gcc
> % puts $env(CC)
> gcc
> % array unset env *
> % puts $env(CC)
>
> % puts [array get env]
> ... CC {} ...
>
> Note how CC in the environment is now blank, but still exists,  
> after the 'array unset env *' (and if you run this yourself, you'll  
> see all the environment variables in that last command are {}).

Confirmed with Apple-provided tcl 8.4.7 on 10.5.2.

> What it should do, and did (I believe) on 10.4 and does with 8.5.2:
>
> % puts $env(CC)
> can't read "env(CC)": no such variable
> % set env(CC) "gcc"
> gcc
> % puts $env(CC)
> gcc
> % array unset env *
> % puts $env(CC)
> can't read "env(CC)": no such variable
> % puts [array get env]
>
> Here, after 'array unset env *' CC is no longer set in the  
> environment.  Which is how it should work.  Note also, the last  
> command doesn't show all env vars as empty but nothing there.

Confirmed with Apple-provided tcl 8.4.7 on 10.4.11.
Confirmed with MacPorts tcl 8.5.2 on 10.4.11.
Confirmed with MacPorts tcl 8.5.2 on 10.5.2.

> We can't use 'array unset env' as that is documented to disconnect  
> Tcl from the environment, and some messing around hasn't shown a  
> clean way to work around this.  Maybe a Tcl expert is needed, and  
> determining if this is Mac-specific or 8.4.7; of course, either  
> way, we have to deal with it.
>
> FYI, this is done in portutil.tcl (base/src/port1.0/) in proc  
> command_exec.

Thanks for the analysis! I added a link to your explanation to http://
trac.macports.org/wiki/LeopardProblems

Do we really not have a macports base ticket for this issue yet? I  
couldn't find one but maybe I'm searching wrong. We need one so that  
we can mark all the other port bugs that are cropping up as  
duplicates of it.

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

[Anders F Björklund-2]

Ryan Schmidt wrote:

>> We can't use 'array unset env' as that is documented to disconnect  
>> Tcl from the environment, and some messing around hasn't shown a  
>> clean way to work around this.  Maybe a Tcl expert is needed, and  
>> determining if this is Mac-specific or 8.4.7; of course, either  
>> way, we have to deal with it.
>>
>> FYI, this is done in portutil.tcl (base/src/port1.0/) in proc  
>> command_exec.
>
> Thanks for the analysis! I added a link to your explanation to  
> http://trac.macports.org/wiki/LeopardProblems
>
> Do we really not have a macports base ticket for this issue yet? I  
> couldn't find one but maybe I'm searching wrong. We need one so  
> that we can mark all the other port bugs that are cropping up as  
> duplicates of it.

As far as I can tell, Apple explicitly enables the use of "putenv" to  
clear out environment variables in Leopard's tcl-64 variant (#define  
USE_PUTENV 1). Whereas the original tcl 8.4.7 (and Tiger's tcl-20.1.4  
too) only uses that on Windows, as far as I can tell. And sets the  
var to NULL otherwise. Still doesn't explain why doing a "port clean"  
and restarting fixes it, but it's a difference between the two  
Tcl-8.4.7's ?

--anders

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

[Bryan Blackburn-4]

On May 13, 2008, at 1:54 AM, Ryan Schmidt wrote:

> On Apr 20, 2008, at 7:09 PM, Bryan Blackburn wrote:
>
> [about the Leopard problem where some ports fail to install properly  
> with a seemingly endless variety of bizarre error messages if  
> installing them causes a dependency to be installed first, but the  
> port succeeds if you try the install a second time (because now it  
> has no dependencies to install)]
...
>
> Thanks for the analysis! I added a link to your explanation to http://trac.macports.org/wiki/LeopardProblems
>
> Do we really not have a macports base ticket for this issue yet? I  
> couldn't find one but maybe I'm searching wrong. We need one so that  
> we can mark all the other port bugs that are cropping up as  
> duplicates of it.
>

Oh, yeah, this issue.  It's coming from a patch in tcl-64 [1] which  
patches Tcl to use putenv() for handling the environment.  I filed a  
radar [2] with Apple and it was closed as a dup so they definitely  
know about it, and maybe 10.5.3 (maybe not since it's pretty close?)  
or 10.5.4 and we shouldn't have to worry about this anymore.

Bryan

[1] - http://www.opensource.apple.com/darwinsource/10.5.2/tcl-64/
[2] - rdar://problem/5878954

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

[Ryan Schmidt-24]

On May 13, 2008, at 3:45 AM, Anders F Björklund wrote:

> Ryan Schmidt wrote:
>
>>> We can't use 'array unset env' as that is documented to  
>>> disconnect Tcl from the environment, and some messing around  
>>> hasn't shown a clean way to work around this.  Maybe a Tcl expert  
>>> is needed, and determining if this is Mac-specific or 8.4.7; of  
>>> course, either way, we have to deal with it.
>>>
>>> FYI, this is done in portutil.tcl (base/src/port1.0/) in proc  
>>> command_exec.
>>
>> Thanks for the analysis! I added a link to your explanation to  
>> http://trac.macports.org/wiki/LeopardProblems
>>
>> Do we really not have a macports base ticket for this issue yet? I  
>> couldn't find one but maybe I'm searching wrong. We need one so  
>> that we can mark all the other port bugs that are cropping up as  
>> duplicates of it.
>
> As far as I can tell, Apple explicitly enables the use of "putenv"  
> to clear out environment variables in Leopard's tcl-64 variant  
> (#define USE_PUTENV 1). Whereas the original tcl 8.4.7 (and Tiger's  
> tcl-20.1.4 too) only uses that on Windows, as far as I can tell.  
> And sets the var to NULL otherwise. Still doesn't explain why doing  
> a "port clean" and restarting fixes it, but it's a difference  
> between the two Tcl-8.4.7's ?

The USE_PUTENV problem was said to have been fixed in tcl 8.5a2 and  
8.4.12 via the 979640-env-hobbs.patch in this ticket:

http://sourceforge.net/tracker/index.php?
func=detail&aid=979640&group_id=10894&atid=110894

However, I downgraded the tcl port to 8.4.7, added -DUSE_PUTENV to  
the CPPFLAGS, and it still was able to unset environment variables  
properly. In other words, I would like to reproduce the problem in  
the MacPorts tcl, but I cannot.

I do see that Apple is #defining USE_PUTENV 1 on Leopard's tcl, but  
they're also patching a lot of other things:

http://www.opensource.apple.com/darwinsource/10.5.2/tcl-64/tcl/tcl.diff

I wonder if maybe some of those other patches are the cause of the  
problem.

I'll look into this problem more later.


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