Glad to help. Figuring out dynamic-linking issues can be a pain, but the information/solution is always out there... somewhere.
- Paul On Wed, Jul 18, 2012 at 11:45 AM, Christian Akesson <[email protected] > wrote: > Tried that out right quick: > File > "W:/Tools/SOEglobal/python/SOEmayaTools/soe_mayaBatch/commandNodes/export.py", > line 6, in <module> > from maya.OpenMaya import MGlobal > File > "c:\buildforge\Maya_2012_Win64_Build\build\wrk\optim\runTime\Python\Lib\site-packages\maya\OpenMaya.py", > line 7, in <module> > ImportError: DLL load failed: The specified procedure could not be found. > > I will look into dynamic-library-path-resolution on windows. Thanks for > your reply. > > /Christian > > > > On Wed, Jul 18, 2012 at 11:34 AM, Paul Molodowitch <[email protected]>wrote: > >> It looks like some sort of dll linking error - for whatever reason, when >> run inside of your app, it looks like it can't find the standard maya dlls. >> >> Try this - instead of doing "from pymel.core import *", just try "from >> maya.OpenMaya import MGlobal". Does that work? If not, you need to look >> into the specific details of dynamic-library-path-resolution on windows, >> and figure out how to get it to find the maya dlls. I don't really know >> much about those details on windows, but I know that on linux, executables >> can add paths onto the list of paths to search for dynamic libs, and those >> paths may be inherited (or even override) the paths for other libraries it >> loads - perhaps something similar exists on windows? >> >> - Paul >> >> On Wed, Jul 18, 2012 at 11:06 AM, Christian Akesson < >> [email protected]> wrote: >> >>> I should also add that the way the batch start module (CA_batcher.py in >>> the UI) is called from the compiled application is the below: >>> >>> def mayaBatch(self): >>> """ Kick off the batch sessions""" >>> # Verify call >>> if self.verifyMayaBatchInputs(): >>> self.updateXMLForMayaBatch() >>> commandPath = soe_path.Path(self.mayaBatchStartUp) >>> sys.path.append(os.path.split(commandPath)[0]) >>> fp, pathname, description = imp.find_module(commandPath.namebase) >>> imp.load_module(commandPath.namebase, fp, pathname, description) >>> >>> /Christian >>> >>> >>> >>> On Wed, Jul 18, 2012 at 11:03 AM, Christian Akesson < >>> [email protected]> wrote: >>> >>>> Hi Justin, thanks for your reply. >>>> >>>> Yes, I am packing into a standalone app, using GUI2EXE and py2exe. The >>>> setup script is attached. The only thing I do special in the setup is the >>>> below portion, which pretty much adds the environment I have in Eclipse to >>>> the system paths (surely the formatting will get shredded): >>>> >>>> import xml.etree.ElementTree as ET >>>> import getpass >>>> import sys >>>> from os import path >>>> remoteTBLoc = '//Sdlux3/Projects2/StudioArt/SOEglobal' >>>> if path.exists("%s/data/%s/SOEG.xml" % (remoteTBLoc, >>>> getpass.getuser())): >>>> userXML = ET.parse('%s/data/%s/SOEG.xml' % (remoteTBLoc, >>>> getpass.getuser())) >>>> userXMLCore = userXML.getiterator('Core')[0] >>>> SOEGUprojectToolPath = userXMLCore.get('SOEprojectToolPath') >>>> sys.path.append('%s/python/SOEcommon' % SOEGUprojectToolPath) >>>> from core import soeg >>>> soeg.SOEG().loadSysPaths(artBuild=0) >>>> else: >>>> print 'ERROR - SOEG needs to be installed' >>>> >>>> >>>> I am confused about one thing. If you look at the ui image attached in >>>> the original post, the actions listed are python modules, that lives in the >>>> Actions Directory package (see ui image). This is dynamically displayed, >>>> and none of them are included in the compiled program. When I run, for >>>> simplicity's sake a single action, the batch starter (see ui) is called. >>>> >>>> In this case, the CA_batcher.py, will for each file that is listed in >>>> the Files & Folder tab kick off a subprocess: >>>> for eachFile in treatFiles: >>>> mayaProcess = subprocess.Popen([mayaPyPath, action, eachFile]) >>>> mayaProcess.wait() >>>> >>>> So a subprocess is created calling mayapy.exe with the action (export) >>>> module being called. I was under the impression that when you call from >>>> pymel.core import * in a mayapy.exe session that your environment was being >>>> initialized and that seems to happen when I run this program the exact same >>>> way inside Eclipse. >>>> >>>> When that failed, I tried to initialize the environment manually in the >>>> action (export) module, but nothing seems to get the from pymel.core import >>>> * to go. >>>> >>>> i.e nothing pymel or Maya is being used inside the compiled program >>>> itself. The only time that is being used is when the subprocess is created >>>> to the external action. >>>> >>>> Could there be some dependency somewhere within the program itself that >>>> causes the subprocess to look inside the compiled exe for pymel? I've >>>> combed for that, but not been able to find anything. >>>> >>>> Thanks for having a look, I'm hoping that I am missing something... >>>> >>>> /Christian Akesson >>>> >>>> >>>> >>>> On Wed, Jul 18, 2012 at 8:23 AM, Justin Israel >>>> <[email protected]>wrote: >>>> >>>>> What are you "compiling" with? Do you mean that you are packaging it >>>>> into a standalone app with something like py2exe or pyinstaller? If so, >>>>> what does your setup file look like? Its most likely related to missing >>>>> dependencies. When you package libraries that have some substantial .dll >>>>> deps it can be a bit of an extra process to specify them so they are >>>>> included. >>>>> Pygame apparently has this same situation, where py2exe will list a >>>>> special "recipe" section for it on the wiki. >>>>> >>>>> >>>>> >>>>> >>>>> On Jul 17, 2012, at 11:19 PM, Christian Akesson < >>>>> [email protected]> wrote: >>>>> >>>>> I've written a standalone compiled Python & PyQt program. It is a >>>>> framework for all things batching, where separate modules can be written >>>>> outside of the main program and then gets read by the main program. >>>>> >>>>> One of the things I set it up to do is doing batch jobs with Maya. >>>>> When developing it in Eclipse, I ran a Python 2.6.4 interpreter (x64) - >>>>> same as Maya 2012 x64 is running on from what I have gathered. Everything >>>>> works like a charm inside Eclipse. I compile the program and the moment I >>>>> run the batch code. which uses mayapy.exe ( >>>>> http://download.autodesk.com/global/docs/maya2012/en_us/PyMel/standalone.html) >>>>> in a subprocess, I get this error spew: >>>>> >>>>> Traceback (most recent call last): >>>>> File >>>>> "W:/Tools/SOEglobal/python/SOEmayaTools/soe_mayaBatch/commandNodes/export.py", >>>>> line 6, in <module> >>>>> from pymel.core import * #@UnusedWildImport >>>>> File "C:\Program >>>>> Files\Autodesk\Maya2012\Python\lib\site-packages\pymel\core\__init__.py", >>>>> line 6, in <module> >>>>> import pymel.versions as _versions >>>>> File "C:\Program >>>>> Files\Autodesk\Maya2012\Python\lib\site-packages\pymel\versions.py", line >>>>> 12, in <module> >>>>> from maya.OpenMaya import MGlobal as _MGlobal >>>>> File >>>>> "c:\buildforge\Maya_2012_Win64_Build\build\wrk\optim\runTime\Python\Lib\site-packages\maya\OpenMaya.py", >>>>> line 7, in <module> >>>>> ImportError: DLL load failed: The specified procedure could not be >>>>> found. >>>>> >>>>> If I remove the from pymel.core import * from that module (export.py), >>>>> it will go into our library and start running the batch. The problem is >>>>> that we have deeply integrated pymel, so whenever it hits that call in our >>>>> other modules, I get that same error. >>>>> >>>>> I've sys.path.append-ed our entire environment manually to make sure >>>>> it's not an environment thing. I've printed out which python version, bit >>>>> depth that is being run in both the main program as well as in the mayapy >>>>> subprocess and they are the same. >>>>> >>>>> Does anyone have any clue to what could be going on here? >>>>> Running Maya 2012 service pack 2 and PyMel 1.0.3 >>>>> >>>>> The fact that it runs like a charm when running inside of eclipse has >>>>> got to be a clue and is really frustrating at the same time :-). >>>>> >>>>> <image.png> >>>>> >>>>> >>>>> >>>>> /Christian >>>>> >>>>> -- >>>>> view archives: http://groups.google.com/group/python_inside_maya >>>>> change your subscription settings: >>>>> http://groups.google.com/group/python_inside_maya/subscribe >>>>> >>>>> -- >>>>> view archives: http://groups.google.com/group/python_inside_maya >>>>> change your subscription settings: >>>>> http://groups.google.com/group/python_inside_maya/subscribe >>>>> >>>> >>>> >>> -- >>> view archives: http://groups.google.com/group/python_inside_maya >>> change your subscription settings: >>> http://groups.google.com/group/python_inside_maya/subscribe >>> >> >> -- >> view archives: http://groups.google.com/group/python_inside_maya >> change your subscription settings: >> http://groups.google.com/group/python_inside_maya/subscribe >> > > -- > view archives: http://groups.google.com/group/python_inside_maya > change your subscription settings: > http://groups.google.com/group/python_inside_maya/subscribe > -- view archives: http://groups.google.com/group/python_inside_maya change your subscription settings: http://groups.google.com/group/python_inside_maya/subscribe
