[lxml-dev] lxml on gcc 4.0
Hi there, I did some hacking against Pyrex to see whether I could make it compile lxml with gcc 4.0. Unguided by any actual knowledge, I created a patch which goes on top of the Red Hat patch, which then is applied to Pyrex 0.9.3. I've attached the two patches. Apply the pyrex-0.9.2.1-gcc4.patch first (it does apply against 0.9.3 too), and then my gcc-4.0-hack.patch. I'd be happy to hear reports on whether this works for others! Regards, Martijn
I've attached the two patches. Apply the pyrex-0.9.2.1-gcc4.patch first (it does apply against 0.9.3 too), and then my gcc-4.0-hack.patch. I'd be happy to hear reports on whether this works for others! I seem to not understand something... The ubuntu package has this
Hi Martijn On Thu, Jun 16, 2005 at 08:33:05PM +0200, Martijn Faassen wrote: patch. I'm lost... Regards -- Misha
Mikhail Sobolev wrote:
Hi Martijn
On Thu, Jun 16, 2005 at 08:33:05PM +0200, Martijn Faassen wrote:
I've attached the two patches. Apply the pyrex-0.9.2.1-gcc4.patch first (it does apply against 0.9.3 too), and then my gcc-4.0-hack.patch. I'd be happy to hear reports on whether this works for others!
I seem to not understand something... The ubuntu package has this patch. I'm lost...
It has the second patch as well? That's surprising as I just wrote it myself. :) In that case lxml should compile; it does on my box.. i.e. I mean this patch (the second one of the two I attached): --- Pyrex-0.9.3/Pyrex/Compiler/ExprNodes.py 2005-06-16 20:24:03.592791856 +0200 +++ Pyrex-0.9.3.patched/Pyrex/Compiler/ExprNodes.py 2005-06-16 20:23:45.027614192 +0200 @@ -1580,18 +1580,16 @@ return NameNode.is_ephemeral(self) def result_code(self): - return self.select_code()[0] + return self.select_code() def result_as_extension_type(self): return self.uncast_select_code() def select_code(self): - orig_code = self.uncast_select_code() + code = self.uncast_select_code() if self.type.is_extension_type: - code = "((PyObject *)%s)" % orig_code - else: - code = orig_code - return code, orig_code + code = "((PyObject *)%s)" % code + return code def uncast_select_code(self): obj_type = self.obj.type @@ -1644,13 +1642,13 @@ code.error_goto(self.pos))) rhs.generate_disposal_code(code) else: - select_code, orig_code = self.select_code() + select_code = self.select_code() if self.type.is_pyobject: rhs.make_owned_reference(code) code.put_decref(select_code, self.type) code.putln( "%s = %s;" % ( - orig_code, + select_code, rhs.result)) rhs.generate_post_assignment_code(code) self.obj.generate_disposal_code(code) Regards, Martijn
Mikhail Sobolev wrote:
Hi Martijn
On Thu, Jun 16, 2005 at 08:33:05PM +0200, Martijn Faassen wrote:
I've attached the two patches. Apply the pyrex-0.9.2.1-gcc4.patch first (it does apply against 0.9.3 too), and then my gcc-4.0-hack.patch. I'd be happy to hear reports on whether this works for others!
I seem to not understand something... The ubuntu package has this patch. I'm lost...
It has the second patch as well? That's surprising as I just wrote it myself. :) In that case lxml should compile; it does on my box.. Yes, exactly this patch. But it does not compile for me. Is it
On Thu, Jun 16, 2005 at 09:12:57PM +0200, Martijn Faassen wrote: possible that you send me privately the generated .c file? So I could compare... Regards -- Misha
Mikhail Sobolev wrote:
On Thu, Jun 16, 2005 at 09:12:57PM +0200, Martijn Faassen wrote:
Mikhail Sobolev wrote:
Hi Martijn
On Thu, Jun 16, 2005 at 08:33:05PM +0200, Martijn Faassen wrote:
I've attached the two patches. Apply the pyrex-0.9.2.1-gcc4.patch first (it does apply against 0.9.3 too), and then my gcc-4.0-hack.patch. I'd be happy to hear reports on whether this works for others!
I seem to not understand something... The ubuntu package has this patch. I'm lost...
It has the second patch as well? That's surprising as I just wrote it myself. :) In that case lxml should compile; it does on my box..
Yes, exactly this patch. But it does not compile for me. Is it possible that you send me privately the generated .c file? So I could compare...
Exactly the patch including even the names of the variable (orig_code) that I introduced? Wow, pretty wild. I'll send along the .c file. Regards, Martijn
On Thu, Jun 16, 2005 at 09:59:05PM +0200, Martijn Faassen wrote:
Exactly the patch including even the names of the variable (orig_code) that I introduced? Wow, pretty wild.
I'll send along the .c file.
That's really wierd :) Here's what patch application would give: $ patch -p1 --dry-run -t < ../pyrex-0.9.2.1-gcc4.bin patching file Pyrex/Compiler/Code.py Reversed (or previously applied) patch detected! Assuming -R. patching file Pyrex/Compiler/ExprNodes.py Reversed (or previously applied) patch detected! Assuming -R. patching file Pyrex/Compiler/Nodes.py Reversed (or previously applied) patch detected! Assuming -R. Hunk #1 succeeded at 484 (offset 12 lines). Hunk #2 succeeded at 1685 (offset 14 lines). $ patch -p1 --dry-run -t < ../gcc-4.0-hack.patch patching file Pyrex/Compiler/ExprNodes.py Reversed (or previously applied) patch detected! Assuming -R. However the .c code that you sent me is not what I get. Your code is exactly what I did manually to make it compilable... :( Wierd, wierd, wierd... Would it be possible that you check the ubuntu package? http://archive.ubuntu.com/ubuntu/pool/main/p/pyrex/pyrex_0.9.3-1ubuntu5.dsc http://archive.ubuntu.com/ubuntu/pool/main/p/pyrex/pyrex_0.9.3.orig.tar.gz http://archive.ubuntu.com/ubuntu/pool/main/p/pyrex/pyrex_0.9.3-1ubuntu5.diff... Regards -- Misha
On Thu, Jun 16, 2005 at 09:59:05PM +0200, Martijn Faassen wrote:
Exactly the patch including even the names of the variable (orig_code) that I introduced? Wow, pretty wild.
I'll send along the .c file.
That's really wierd :)
Here's what patch application would give:
$ patch -p1 --dry-run -t < ../pyrex-0.9.2.1-gcc4.bin patching file Pyrex/Compiler/Code.py Reversed (or previously applied) patch detected! Assuming -R. patching file Pyrex/Compiler/ExprNodes.py Reversed (or previously applied) patch detected! Assuming -R. patching file Pyrex/Compiler/Nodes.py Reversed (or previously applied) patch detected! Assuming -R. Hunk #1 succeeded at 484 (offset 12 lines). Hunk #2 succeeded at 1685 (offset 14 lines). $ patch -p1 --dry-run -t < ../gcc-4.0-hack.patch patching file Pyrex/Compiler/ExprNodes.py Reversed (or previously applied) patch detected! Assuming -R.
However the .c code that you sent me is not what I get. Your code is exactly what I did manually to make it compilable... :( Wierd, wierd, wierd... I downloaded sources of Pyrex from their home page. And the reaction on
On Fri, Jun 17, 2005 at 01:13:13AM +0400, Mikhail Sobolev wrote: the second patch is exactly the same: previously applied patch detected. Any hints? :) Regards -- Misha
On Thu, Jun 16, 2005 at 09:12:57PM +0200, Martijn Faassen wrote: [...]
i.e. I mean this patch (the second one of the two I attached):
[...]
def select_code(self): - orig_code = self.uncast_select_code() + code = self.uncast_select_code() if self.type.is_extension_type: - code = "((PyObject *)%s)" % orig_code - else: - code = orig_code - return code, orig_code + code = "((PyObject *)%s)" % code + return code
[...] On Thu, Jun 16, 2005 at 09:59:05PM +0200, Martijn Faassen wrote:
Mikhail Sobolev wrote: [...]
Yes, exactly this patch. But it does not compile for me. Is it possible that you send me privately the generated .c file? So I could compare...
Exactly the patch including even the names of the variable (orig_code) that I introduced? Wow, pretty wild.
I think the problem is that your patch is reversed, as you can see from the snippet I quote above :) -Andrew.
On Fri, Jun 17, 2005 at 12:59:17PM +1000, Andrew Bennetts wrote:
I think the problem is that your patch is reversed, as you can see from the snippet I quote above :) You are right indeed. :) When I agreed with the patch program and confirmed it's 'reversed', it applied without a problem and then the lxml would happily build. :)
Thanks a lot! Regards -- Misha
Andrew Bennetts wrote:
On Thu, Jun 16, 2005 at 09:12:57PM +0200, Martijn Faassen wrote: [snip]
Exactly the patch including even the names of the variable (orig_code) that I introduced? Wow, pretty wild.
I think the problem is that your patch is reversed, as you can see from the snippet I quote above :)
Aah, sorry about that, I wonder how I ended up doing that. Attached a new patch, though I saw Olivier also attached a cumulative one. Thanks for the hint. :) Regards, Martijn
Martijn Faassen wrote:
Hi there,
I did some hacking against Pyrex to see whether I could make it compile lxml with gcc 4.0. Unguided by any actual knowledge, I created a patch which goes on top of the Red Hat patch, which then is applied to Pyrex 0.9.3.
I've attached the two patches. Apply the pyrex-0.9.2.1-gcc4.patch first (it does apply against 0.9.3 too), and then my gcc-4.0-hack.patch. I'd be happy to hear reports on whether this works for others!
Thanks for your patch, it works for me :) My system: fresh FC4 with gcc4 with a Pyrex-0.9.3 patched twice + current svn lxml and python 2.4.1. lxml was successfully built and all tests pass. You should submit your patch to the pyrex devs if not already done. Best, -- Olivier
BTW, here is a summary patch to apply against a vanilla Pyrex-0.9.3 to make it generate gcc4-valid code. This comprises both the two previous patches (RH's and Martijn's) combined into one. -- Olivier
Hey, Because I thought the whole open source process functioned in a cool way the last couple of days surrounding the gcc 4.0 issue, I posted a blog entry about it: http://faassen.n--tree.net/blog/view/weblog/2005/06/17/0 You guys are mentioned. :) Regards, Martijn
Martijn Faassen wrote:
Hey,
Because I thought the whole open source process functioned in a cool way the last couple of days surrounding the gcc 4.0 issue,
Yes, that's especlially the case with python based project, I think. For instance, look at the BZR ML archives: http://news.gmane.org/gmane.comp.version-control.bazaar-ng.general/ Almost half of the threads subjects start with "[PATCH]". That's really amazing, especially for a 4 months old project. Python really makes it easy to get into the code :)
I posted a blog entry about it:
http://faassen.n--tree.net/blog/view/weblog/2005/06/17/0
You guys are mentioned. :)
Thanks. Let's who the fix will be included in the next official Pyrex release :) -- Olivier
participants (4)
-
Andrew Bennetts -
Martijn Faassen -
mss＠mawhrin.net -
Olivier Grisel