The freeze tool used for compiling Python binaries with frozen modules no longer works with Python 3.x.It looks like it was never updated to the various path and symbols changes introduced withPEP 3149 (ABI tags) in Python 3.2.Even with lots of symlinks to restore the non-ABI flagged names, freezing fails with a linker error in Python 3.3:Tools/freeze> python3 freeze.py hello.pyTools/freeze> makeconfig.o:(.data+0x38): undefined reference to `PyInit__imp'collect2: ld returned 1 exit statusmake: *** [hello] Error 1

See also issue#11824 for the ABI tags changes.

As mentioned, the ABI issues are being handled inissue11824.  I believe the linking problems in this issue have to do with the changes that were made in 3.3 to bootstrap importlib into Python.  I will look into it more.

After applying the fix forissue11824 to tip there ended up being three moreissues:   1. makeconfig.py should have been updated ind777f854a66e when changing      imp to _imp.  Without this change a reference to 'PyInit__imp'      was being generated, but that function does not actually exist.   2. After fixing (1) I hit an issue where '_frozen_importlib' can      not be found while bringing up the interpreter.   3. After fixing (2) I hit the following error when running the      simple frozen hello app:         $ ./hello          Traceback (most recent call last):               ...           File "/Users/meadori/Code/src/cpython/Lib/site.py", line 578, in main             setcopyright()           File "/Users/meadori/Code/src/cpython/Lib/site.py", line 438, in setcopyright             here = os.path.dirname(os.__file__)         AttributeError: 'module' object has no attribute '__file__'      This happens during 'initsite' and is because of a change made      to remove the __file__ attribute from frozen modules in702009f3c0b1.The attached patch fixes (1) by filtering '_imp' instead of 'imp' inmakeconfig.py, (2) by making sure '_frozen_importlib' is in the frozenmodule table created by freeze.py, and (3) by removing the code to delete__file__ from frozen modules.I am a little unsure about (3) since I am not sure why the __file__ attributeis being removed to begin with.  eric.smith?

On Jan 02, 2013, at 04:06 PM, Meador Inge wrote:>I am a little unsure about (3) since I am not sure why the __file__ attribute>is being removed to begin with.  eric.smith?This is related toPEP 420, which relaxes the requirement that all moduleshave a __file__ attribute.  Now they only need it if it makes sense.  At thetime, we didn't think it made sense for frozen modules to have an __file__.FrozenImporter.module_repr() provides a reasonable repr in the absence of__file__.I'm not sure what to do.  I still think it doesn't make a lot of sense forfrozen modules to have an __file__, but perhaps practicality beats purityhere.

What Barry said. :)I haven't had time to check yet: but why does site.py need the __file__ attribute? Maybe that's the actual problem.

On Jan 02, 2013, at 04:29 PM, Eric V. Smith wrote:>I haven't had time to check yet: but why does site.py need the __file__>attribute? Maybe that's the actual problem.It uses it to find the license text when you type license() at the interactiveprompt.  I think setcopyright() should just ignore that if os.__file__ isn'tdefined.  Why would you be printing the license at a prompt in a frozenPython?

I agree that it makes no sense to define __file__ for frozen modules. Originally they did because that was the only way to tell if a module was a builtin module or not, but with the imp module's API on top of sys.builtin_module_names, there is no need to maintain this invariant.As for site.py requiring the module to have a __file__ on os, I think that is somewhat bogus as well and should be optional so issue (3) for Meador should be to patch site.py to not flat-out require os.__file__ exist.

Thanks for the feedback everyone -- that helped.  Here is a new patchwhich addresses issue (3) by not requiring os.__file__ to exist.The patch fromissue11824 fixes freeze for 3.2 completely.  The patchfromissue11824 plus this patch fixes freeze for 3.3 and 3.4.  I testedboth `make install` and Python source tree versions (i.e. freeze.py -p).A frozen "Hello, world" app works fine in all cases.I also verified that 'license' works from a frozen app.  You will seesomething like the following instead of the full licensing text on stdout:   Seehttp://www.python.org/3.4/license.html

Thanks for the patches. After applyingissue11824-0.patch and then isse16047-1.patch I am successfully able to freeze a hello world python script under ubuntu 14.04 with python 3.4 rc3. I have attached my new site.py file, since the automatical patch application did not run through.However, in my productive project I need the psycopg2 library for database access. Whenever using 'import psycopg2' in my code the binary shows a runtime error that it cannot find the module psycopg2._psycopg. A one line script suffices for reproduction. Executing the script without freezing it works like a charm. In Python 3.2 it helped to create  in the working dir a psycopg2 subdir with a symlink  _psycopg.so -> /usr/lib/python3/dist-packages/psycopg2/_psycopg.cpython-32mu.so . This seems no longer help. Is this a bug/feature of freeze or psycopg2? Thanks for your interest and help.

Did you want to update your patch for Python 3.4 and 3.5, Meador?

Sure.  I will refresh it tonight or sometime tomorrow.

Same issue with external libraries under (pachted) Python 3.4.0 final on Ubuntu 14.04 LTS or Debian Wheezy/Sid.Meader, is there any option/possibility zu use an external library (like psycopg2.psycopg.so)from the freezed binary? I alreday tried to manually add various -L -l options to the linker command of the generated make file or adjust LD_LIBRARY_PATH and so on ... always without any success. Unfortunately, I need this for a large productive system Praktomat. Please help.Thanks again.Chris

I also issued a ticket at the bugtracker of the psycopg2 project:http://psycopg.lighthouseapp.com/projects/62710/tickets/201

Christian: please don't use this bug tracker to get help. Please use e.g. python-list to ask questions on how to use Python. To answer your question: in theory, you have the choice to either continue to use dynamic loading from the frozen interpreter, or to make psycopg.so a builtin module. Freeze won't help here, as it only deals with modules written in Python.

Will these patches still make it into the Python 3.4 branch ?

Martin: this is clearly a bug, as it is now (Python 3.3 onwards) impossible to use an external module (in a .so) from a frozen binary. The phrase "please help" was intended to fix the bug. If there is a new option then this would also result in some kind of a bug, since nowhere documented. It turns freeze.py unusable in many situations. At least it cannot be done as in Python 3.2 (described above) and the many other methods I tried. The mailing list can only be a last option, since Meador's patches are nowhere officially included and thus not very widespread. Unfortunately, both of your advices only work in theory for me. However, I am glad to have found in you a person who gives at least some advices.Meanwhile, the psycopg guys are do (also) not see a bug on their side:http://psycopg.lighthouseapp.com/projects/62710/tickets/201

On 25.03.2014 11:37, Christian Bachmaier wrote:> > Martin: this is clearly a bug, as it is now (Python 3.3 onwards) impossible to use an external module (in a .so) from a frozen binary. Are you sure about this ?If you freeze an application which imports just the _psycopg*.so fileand make sure the linker can find it, does the import still fail fromthe frozen app ?

# ldd hello        linux-vdso.so.1 =>  (0x00007fffd677e000)        libpython3.4m.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 (0x00007f968c6c2000)        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f968c4a4000)        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f968c0dd000)        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f968beb3000)        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f968bc9a000)        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f968ba95000)        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f968b892000)        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f968b58c000)        /lib64/ld-linux-x86-64.so.2 (0x00007f968ccfb000)and (even strace) does not show an attempt to acces the so-file. Also tried to add-L/usr/lib/python3/dist-packages/psycopg2 -l_psycopg.cpython-34m-x86_64-linux-gnu.soand similar without success.Can anyone try to reproduce it, a freeze (with patches) of hello.py containing onlyimport _psycopg2or maybe another external library? In the first case apt-get install python3-psycopg2 is necessary.

Apologies for not replying over the weekend.  I am still looking into this one.

On 25.03.2014 13:02, Christian Bachmaier wrote:> > Christian Bachmaier added the comment:> > # ldd hello>         linux-vdso.so.1 =>  (0x00007fffd677e000)>         libpython3.4m.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython3.4m.so.1.0 (0x00007f968c6c2000)>         libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f968c4a4000)>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f968c0dd000)>         libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f968beb3000)>         libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f968bc9a000)>         libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f968ba95000)>         libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f968b892000)>         libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f968b58c000)>         /lib64/ld-linux-x86-64.so.2 (0x00007f968ccfb000)> > and (even strace) does not show an attempt to acces the so-file. Also tried to add> > -L/usr/lib/python3/dist-packages/psycopg2 -l_psycopg.cpython-34m-x86_64-linux-gnu.so> > and similar without success.> > Can anyone try to reproduce it, a freeze (with patches) of hello.py containing only> > import _psycopg2> > or maybe another external library? In the first case apt-get install python3-psycopg2 is necessary.Christian, what you're expecting is not what freeze can offer.The shared library is not linked into the resulting binaryby simply having an import in the Python file. freeze doessupport adding the external library statically, but it's noteasy.See the eGenix PyRun source archive for how it's done:http://www.egenix.com/products/python/PyRun/The question I raised was whether running "hello" willfail to import the shared library _pyscopg2*.so or not.If that's the case (and only then), you have found a bug thatneeds fixing. If not, please ask your usage questions on otherlists. This ticket is about getting freeze working again forPython 3.x, not about its usage.Thanks,-- Marc-Andre LemburgeGenix.com

The shared library is not linked into the resulting binaryby simply having an import in the Python file.Yes. This is why (at least in Python 3.2) it must be in the right path (subdirectory), see above.> freeze does> support adding the external library statically, but it's not> easy.Unfortunately, Debian/Ubuntu does not deliver a static version of psycopg2. So I'd like to use the dynamic version. This is definitively possible with Python 3.2 x86, again, see above.> The question I raised was whether running "hello" will> fail to import the shared library _pyscopg2*.so or not.That's a good question. I think so, but how can I test that? At least the (only) way in Python 3.2 does not work any more. Even with Python 3.2 there must be a link in the subdirectory as shown above. It is not enough to have it only in the usual installation directory /usr/lib/python3/dist-packages/psycopg2/_psycopg.xxx.soEven any set LD_LIBRARY_PATH is ignored, like also putting it in /usr/lib as far as I can see.> This ticket is about getting freeze working again for> Python 3.xRight. So we should test the library feature which worked somehow magically in Python 3.2. Then we will see if it is a bug. My statement is that it is a bug.Thanks again to all.

Sorry I forgot: PyRun seems only support Python 2.x.The only other freeze tool I know for Pyhton3 code is cx_freeze. I would prefere the vanilla freeze of the python distribution itself and as far as I can see using cx_freeze makes more problems for me as it may solve. But that is not a discussion for this thread or forum.

On 25.03.2014 16:21, Christian Bachmaier wrote:> > Sorry I forgot: PyRun seems only support Python 2.x.Right, because PyRun uses freeze and freeze currently does not workfor Python 3. Which is what this ticket is all about and whyI opened it.To test what I asked for, please run freeze on this script:"""import _psycopg2print ('Works.')"""If it prints 'Works.', then your problem is unrelated to thisticket. If it fails with an import error or some other errorrelated to loading the shared lib, then it may be a problemwith freeze and is likely related to the new import libmachinery.Thanks,-- Marc-Andre LemburgeGenix.com

> To test what I asked for, please run freeze on this script:> > """> import _psycopg2> print ('Works.')> """$ xxx/freeze.py hello.py$ make$ ./helloTraceback (most recent call last):  File "hello.py", line 3, in <module>    import _psycopg2  File "/usr/lib/python3.4/importlib/_bootstrap.py", line 2214, in _find_and_load    return _find_and_load_unlocked(name, import_)  File "/usr/lib/python3.4/importlib/_bootstrap.py", line 2201, in _find_and_load_unlocked    raise ImportError(_ERR_MSG.format(name), name=name)ImportError: No module named '_psycopg2'Btw the same with import psycopg2, psycopg2._psycopg, or _psycopg. Event with the subdir link as explained above. The first one (import psycopg2) is the one which operates in interpretation mode.> If it prints 'Works.', then your problem is unrelated to this> ticket.Nop, prints the error message instead of 'Works.'> If it fails with an import error or some other error> related to loading the shared lib, then it may be a problem> with freeze and is likely related to the new import lib> machinery.=> we have a bug if Marc-Andre is right. Thanks.Chris

On 25.03.2014 17:47, Christian Bachmaier wrote:> > Christian Bachmaier added the comment:> >> To test what I asked for, please run freeze on this script:>>>> """>> import _psycopg2Sorry. The above should have read "import _psycopg".>> print ('Works.')>> """> > $ xxx/freeze.py hello.py> $ make> $ ./hello> Traceback (most recent call last):>   File "hello.py", line 3, in <module>>     import _psycopg2>   File "/usr/lib/python3.4/importlib/_bootstrap.py", line 2214, in _find_and_load>     return _find_and_load_unlocked(name, import_)>   File "/usr/lib/python3.4/importlib/_bootstrap.py", line 2201, in _find_and_load_unlocked>     raise ImportError(_ERR_MSG.format(name), name=name)> ImportError: No module named '_psycopg2'> > Btw the same with import psycopg2, psycopg2._psycopg, or _psycopg. Event with the subdir link as explained above. The first one (import psycopg2) is the one which operates in interpretation mode.Ok, now we're getting closer.Could you run this to have Python print the locations whereit looks for the shared lib:export PYTHONVERBOSE=2./helloThis should print a long list of messages such as these:import os # frozenimport errno # builtinimport posix # builtinimport posixpath # frozen...to stderr. Of those only the lines which mention _psycopg are relevant.Please make sure that the dir where the .so file resides isincluded in this list. If not, you will need to adjust PYTHONPATHaccordingly.If the dir is mentioned in the listing, we have to dig deeperusing strace or similar.Thanks,-- Marc-Andre LemburgeGenix.com

$ cat hello.pyimport _psycopgprint('Works.')$ export PYTHONVERBOSE=2$ ./hello 2> res.txt$ cat res.txt | grep psycopg           # trying /export/scratch/chris/pgtest/_psycopg.cpython-34m-x86_64-linux-gnu.so# trying /export/scratch/chris/pgtest/_psycopg.cpython-34m.so# trying /export/scratch/chris/pgtest/_psycopg.abi3.so# trying /export/scratch/chris/pgtest/_psycopg.so# trying /export/scratch/chris/pgtest/_psycopg.py# trying /export/scratch/chris/pgtest/_psycopg.pyc# trying /usr/lib/python3.4/_psycopg.cpython-34m-x86_64-linux-gnu.so# trying /usr/lib/python3.4/_psycopg.cpython-34m.so# trying /usr/lib/python3.4/_psycopg.abi3.so# trying /usr/lib/python3.4/_psycopg.so# trying /usr/lib/python3.4/_psycopg.py# trying /usr/lib/python3.4/_psycopg.pyc# trying /usr/lib/python3.4/plat-x86_64-linux-gnu/_psycopg.cpython-34m-x86_64-linux-gnu.so# trying /usr/lib/python3.4/plat-x86_64-linux-gnu/_psycopg.cpython-34m.so# trying /usr/lib/python3.4/plat-x86_64-linux-gnu/_psycopg.abi3.so# trying /usr/lib/python3.4/plat-x86_64-linux-gnu/_psycopg.so# trying /usr/lib/python3.4/plat-x86_64-linux-gnu/_psycopg.py# trying /usr/lib/python3.4/plat-x86_64-linux-gnu/_psycopg.pyc# trying /usr/lib/python3.4/lib-dynload/_psycopg.cpython-34m-x86_64-linux-gnu.so# trying /usr/lib/python3.4/lib-dynload/_psycopg.cpython-34m.so# trying /usr/lib/python3.4/lib-dynload/_psycopg.abi3.so# trying /usr/lib/python3.4/lib-dynload/_psycopg.so# trying /usr/lib/python3.4/lib-dynload/_psycopg.py# trying /usr/lib/python3.4/lib-dynload/_psycopg.pyc# trying /usr/local/lib/python3.4/dist-packages/_psycopg.cpython-34m-x86_64-linux-gnu.so# trying /usr/local/lib/python3.4/dist-packages/_psycopg.cpython-34m.so# trying /usr/local/lib/python3.4/dist-packages/_psycopg.abi3.so# trying /usr/local/lib/python3.4/dist-packages/_psycopg.so# trying /usr/local/lib/python3.4/dist-packages/_psycopg.py# trying /usr/local/lib/python3.4/dist-packages/_psycopg.pyc# trying /usr/lib/python3/dist-packages/_psycopg.cpython-34m-x86_64-linux-gnu.so# trying /usr/lib/python3/dist-packages/_psycopg.cpython-34m.so# trying /usr/lib/python3/dist-packages/_psycopg.abi3.so# trying /usr/lib/python3/dist-packages/_psycopg.so# trying /usr/lib/python3/dist-packages/_psycopg.py# trying /usr/lib/python3/dist-packages/_psycopg.pyc    import _psycopgImportError: No module named '_psycopg'----$ cat hello.pyimport _psycopgprint('Works.')$ export PYTHONPATH=/usr/lib/python3/dist-packages/psycopg2:$PYTHONPATH$ ./helloWorks.----The correct import (see the doc of psycopg2) is import psycopg2. Otherwise a valid script does even not run in interpreted mode. The library lies in /usr/lib/python3/dist-packages/psycopg2/_psycopg.cpython...so Maybe there is the Problem. One has to Import the parent dir of the so-file, which Triggers the bug.$ cat hello.pyimport psycopg2print('Works.')$ export PYTHONVERBOSE=2$ ./hello 2> res.txt$ cat res.txt | grep psycopg               import psycopg2  File "/usr/lib/python3/dist-packages/psycopg2/__init__.py", line 67, in <module>    from psycopg2._psycopg import BINARY, NUMBER, STRING, DATETIME, ROWIDImportError: No module named 'psycopg2._psycopg'# destroy psycopg2Marc-Andre: would you mind to install python3-psycopg2 to see that in real?

OK, so trying to import around the package was definitely why the first instance didn't work so that's all expected.As for the failure when importing psycopg2, my guess is that the freezing of psycopg2.__init__ is not setting __path__ to anything reasonable to work with dynamically loading psycopg2._psycopg. That really shouldn't really ever work anyway since that just doesn't make sense from the perspective of freezing a package unless you made the extension module a built-in module, but I don't think submodules are supported in that case right now anyway.MAL, do you agree with that assessment?

On 25.03.2014 19:27, Brett Cannon wrote:> > Brett Cannon added the comment:> > OK, so trying to import around the package was definitely why the first instance didn't work so that's all expected.> > As for the failure when importing psycopg2, my guess is that the freezing of psycopg2.__init__ is not setting __path__ to anything reasonable to work with dynamically loading psycopg2._psycopg. That really shouldn't really ever work anyway since that just doesn't make sense from the perspective of freezing a package unless you made the extension module a built-in module, but I don't think submodules are supported in that case right now anyway.> > MAL, do you agree with that assessment?Using C extensions embedded in Python packages is supported inPython 2's freeze - but not directly:This works because Python2 search for the module in the top leveldirectories in case it cannot find the shared mod in the package dir(which in the case of frozen packages does not exist). So you ship thefrozen app together with the .so shared module in the same directoryor setup sys.path to point to whatever dir you use for this.I'll have to have a look at how the pyscopg2 package normallyimports its C extension. It's likely that they will have to usesomething like this to make things work for frozen apps as well:try:    from psycopg2 import _psycopgexcept ImportError:    # try to find the module at the top-level    import _psyocpgor setup the package's .__path__ to include the top-leveldir.

On 25.03.2014 19:41, M.-A. Lemburg wrote:> I'll have to have a look at how the pyscopg2 package normally> imports its C extension. It's likely that they will have to use> something like this to make things work for frozen apps as well:> > try:>     from psycopg2 import _psycopg> except ImportError:>     # try to find the module at the top-level>     import _psyocpg> > or setup the package's .__path__ to include the top-level> dir.The package uses absolute imports for importing the C extension, e.g.from psycopg2._psycopg import __version__This cannot work in Python with frozen packages. Not in Python 2 andnot in Python 3 either.Christian: Your only option is not to freeze the psycopg2 packageand ship it along side your frozen application or to build thefrozen app with the psycopg2 C extension built statically.In any case, freeze is not at fault here.

Wait, Brett :-)The issue that Christian mentioned was just a side discussion.We still need to fix the main problem.

Sorry guys, library loading of a freezed binary is different to interpreter mode. This is a bug in freeze, or at least an undocumented missing feature of freeze. This is no side discussion.And, in Python 3.2 this was working! As described above, just creating a subdir psycopg2 in the working direktory of the frozen binary containing a link _psycopg.so to the library. This is a fact. I have two working production systems using this mechanism under Ubuntu 12.04 LTS.Ok, psycopg2 seems to load the so file indirectly over __init__.py, however, the interpreter and older versions of freeze support that. The psycopg2 guys do not see any problem in that, see the closed entry linked above in their bug database.A workaround/hack I am using successfully now is to replace any 'import psycopg2._psycopg' by 'import _psycopg' in all /usr/lib/python3/dist-packages/psycopg2/*.py files and to set PYTHONPATH=//usr/lib/python3/dist-packages/psycopg2 prior execution of the frozen binary. I found this only by playing around several days, there is NO documentation about that. The advices statically linking etc. given here are too superficial. Any more helful/concrete advices (outside of this thread) seem to cost money.I wanted and still want help to fix this by giving detailed reports.

Christian: Please understand that it was not helpful to post into this issue. The issue discussed here is separate from the issue you are having. We prefer a strict "one issue at a time" policy in this tracker.So when this issue gets closed because Marc-Andre's original problem is solved, feel free to report your issue again.

Christian, please open a separate ticket for your problem.This ticket is about getting freeze, the tool itself, working,not any other issue you may find with the resulting frozen binary.Thanks,-- Marc-Andre LemburgeGenix.com

New changeset001a6dc996e7 by Martin v. Löwis in branch '3.4':Issue#16047: Fix module exception list and __file__ handling in freeze.http://hg.python.org/cpython/rev/001a6dc996e7New changeset87ded2fdac4b by Martin v. Löwis in branch 'default':Merge 3.4 (#16047)http://hg.python.org/cpython/rev/87ded2fdac4b

Thanks for the patch. It seems to work now.http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%20Freeze%203.x/builds/9

Apologies for not getting around to applying this myself.  I had an extremely busy week with the day job last week.  Thanks for applying Martin.