From: Jonathan B. <jbr...@ea...> - 2004-01-26 03:42:12
|
On Sun, 2004-01-25 at 18:22, Martin Costabel wrote: > Jonathan Brandmeyer wrote: > > > > Excellent, I got it. I have a build going as I write this on a 10.2 box > > with Python 2.2 and an Apple-distributed GCC 3.1. > > Yes, I found now that the error I am seeing comes from using gcc-3.3 > which is the standard on OSX 10.3. It goes away when I use gcc-3.1. It > seems that the CXX library does not work with gcc-3.3. This is really > weird, because all these things are in the end linked with the python2.3 > executable which was compiled with gcc-3.3, and C++-compiled binaries > are, in general, not compatible between gcc-3.1 and gcc-3.3. It isn't an issue because the interface between cvisualmodule.so and Python(.exe) is exclusively C-based, and the C ABI did not change between those releases. The only conflict would arise if you linked some other shared object to cvisualmodule.so, which I can't imagine anyone doing. > Anyway, if no solution is found to make the CXX stuff compatible with > gcc-3.3, I can require that the package is built with gcc-3.1, crossing > fingers that this will not break other things. > > > cvisual/Makefile is totally insensitive to the DESTDIR variable, exactly > > why is it needed? Is the makefile not picking up on the value of > > 'prefix' for some reason? > > It is, but the fink build process is like with debian or rpm: You don't > install to the final destination, but to some build-root from which the > package is then created. Thus the prefix is set to /sw (%p in the info > file), but the make install has to install into > /sw/src/root-visual-py23-2.1.9-1/sw/ > > Hence the need for the DESTDIR variable which is respected in all > subdirectories except cvisual. cvisual/Makefile installs the vpython > script directly into /sw/bin which is illegal, because in this way it > does not get into the package. OK. I'll put this change into CVS. > > > With the changes that your patch makes to OSX_SORULE, the link step > > fails with many undefined references to functions defined in the Python > > executable itself. > > The "-bundle_loader $PYTHON" flag takes care of this. It tells ld to > look for undefined symbols in the python executable. There was just a > syntax error: -bundle_loader doesn't take a "=" sign. I removed the > -flat_namespace, because the python executable is compiled as a > two_level binary, but I guess this doesn't make much difference. > In any case, it compiled OK for me, both with gcc-3.3 and with gcc-3.1. It was the "=" sign that was the problem, I didn't see notice that before. I'll put this into CVS as well. > > Just exactly what does that sed script do? I've never used sed. > > This is something completely unimportant. I wanted to have something > other than the license.txt in the doc directory. For every fink package > there is a doc directory in /sw/share/doc, in this case > /sw/share/doc/visual-py23. I took the docs/index.html to put there, > renamed to visual.html, and the sed changes the links in that file so > that they point to the other local vpython html files in > /sw/lib/python2.3/site-packages/visual/docs. I don't know enough about > the inner workings of vpython to see whether the latter need to remain > in the site-packages/visual/docs directory or whether they could be > moved to /sw/share/doc/visual, so I let them where they were installed > by default. No, they don't need to be in any place special. We did that for a distribution-independent location, and I fully expect distributors to rearrange file locations as required to satisfy the distribution's policies. > > What command do you execute to build the package? (eg, the counterpart > > to dpkg-buildpackage in Debian). > > The command is simply "fink install visual-py23". Fink actually creates > a *.deb package and then uses dpkg to install it at its final > destination. If one wants to build only the deb package without > isntallation, the command is "fink build visual-py23". > > The package will first go into the unstable tree, so that fink users > will have to activate this. After some time, it will migrate to the > stable tree, and in this case it can then become part of Fink's binary > distribution. When this is achieved, Fink users can use "apt-get install > visual-py23" to get the precompiled binary directly. > > > visual/Makefile byte-compiles site-packages/visual/*.py already, why is > > the post-install script doing this as well? > > I saw that the *.pyc files have the buildroot directory hardwired inside > and suspected that this could have something to do with my error, so I > compiled them a second time after they were installed at their final > place. But I think this is useless, after all. OK, while I wrote this, I > compiled it again without this PostInstScript, and the ball is still > bouncing, so I guess I'll remove this part. If the *.pyc files have something wrong with them, then they would normally be recompiled on use, but since normal users don't have access to that directory, it is silently ignored and the interpreter will use the plain .py files instead. The only consequence would be a slightly slower module loading time. So, if there is a problem, you should probably go ahead and re-run py-compile on those files. > > Another question: I read Kelvin Chu's installation instructions, and he > says that gdbm3 is needed, too. Is this true? I don't see anything > gdbm-related in the compile log. Is that the GNU Database Manager? AFAIK it isn't needed. Thanks again, Jonathan Brandmeyer |