[AG-TECH] Building failure - strange behaviour with pyGlobus
Thomas D. Uram
turam at mcs.anl.gov
Mon Sep 6 10:58:48 CDT 2004
You're right, it likely has to do with the change in flavor. Lately
I've come to understand that we should only be using debug-built globus,
hence the change to gcc32dbgpthr.
Joseph: If you build globus with flavor gcc32dbgpthr, are these
problems resolved for you?
Chris Willing wrote:
> On Fri, 2004-09-03 at 15:34, Joseph wrote:
>>In fact, since the Beta2 release, my build isn't working anymore. The
>>pyGlobus module isn't build. In my build output, I find a lot of :
>>Checking for which modules to build
>>Checking the util module
>>Missing dependency to build the util package.
>>This package is required to build all of pyGlobus.
>>The following is the error message from globus-makefile-header.
>>('No packages were found that matched your query!\n',)
>>Now exiting from the build."
>>And so on, then
>>"ImportError: No module named pyGlobus"
>>Nothing had changed between the Beta1 and the Beta2 on my pc, so I filed a
>>bug report but apparently it wasn't one, the trouble should be with my
>>installation of environment variables.
> I believe this is due to a change in packaging/BuildPythonModules.py, in
> which the value of the flavor argument when building pyGlobus for linux
> has recently changed from 'gcc32pthr' to 'gcc32dbgpthr' (at line 71).
> Reverting to
> flavor = 'gcc32pthr'
> allows a build to complete and allows the post installation script
> AccessGrid-Postinstall.py to complete without error. It also allows
> certmgr.py to run again, so I suspect it will allow VenueClient to run
> again too (all of these previously had the same run time error about
> lack of pyGlobus), but I'm currently not anywhere I can test that till
> tomorrow morning.
> Still, I guess there was some reason to change flavor's value from
> 'gcc32pthr' to 'gcc32dbgpthr', which a reversion won't help.
More information about the ag-tech