Building new SWIG

Hi all,

Thanks to some help from Robin, I've gotten further on my quest to compile SWIG. Now, however, I'm getting strange errors that seem to indicate that it is not linking against the Python lib (or TCL, or Perl, etc.) when building the libswig<lang> library. This is baffling me... I don't think it could be because I'm on Panther... If no one here has seen this before, I'll post this over on the SWIG group. Here's the sample output for Python (I manually skipped Tcl and Perl although they both give similar errors):

mv -f .libs/libswigpy_la-libpy.lo libswigpy_la-libpy.lo
/bin/sh ../libtool --mode=link gcc -g -O2 -Wall -o libswigpy.la -rpath /usr/local/lib -no-undefined libswigpy_la-libpy.lo -ldl
rm -fr .libs/libswigpy.la .libs/libswigpy.* .libs/libswigpy.*
gcc -r -keep_private_externs -nostdlib -o .libs/libswigpy.0.0.0.dylib-master.o libswigpy_la-libpy.lo && gcc -dynamiclib -o .libs/libswigpy.0.0.0.dylib .libs/libswigpy.0.0.0.dylib-master.o -ldl -lc -install_name /usr/local/lib/libswigpy.0.dylib -compatibility_version 1 -current_version 1.0
ld: Undefined symbols:
_PyDict_SetItemString
_PyErr_SetString
_PyExc_NameError
_PyExc_TypeError
_PyFloat_FromDouble
_PyInt_FromLong
_PyObject_CallObject
_PyObject_GetAttr
_PyObject_SetAttrString
_PyString_AsString
_PyString_FromString
_PyString_Type
_PyType_IsSubtype
_PyType_Type
_Py_BuildValue
__Py_NoneStruct
/usr/bin/libtool: internal link edit command failed

Sorry if I'm missing something simple here...

Thanks,

Kevin

Kevin Ollivier wrote:

Hi all,

Thanks to some help from Robin, I've gotten further on my quest to compile SWIG. Now, however, I'm getting strange errors that seem to indicate that it is not linking against the Python lib (or TCL, or Perl, etc.) when building the libswig<lang> library. This is baffling me... I don't think it could be because I'm on Panther... If no one here has seen this before, I'll post this over on the SWIG group. Here's the sample output for Python (I manually skipped Tcl and Perl although they both give similar errors):

I have the same errors on OS X 10.2 with autotools from fink, and Dave B. from SWIG mentioned it over the weekend that he is working on figuring out the problem.

Since wxPython doesn't need the swig runtime library (it's included in the wxPython build as libpy.c) I just ignore this error and just do a "make install". The swig executable and the rest of the swig lib will be installed and then you'll get this error again as it tries again to build the runtime shared libs, but everything I need has already been installed so it is okay.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Hi Robin,

Thanks! You are, as always, right. <G> I now have a working development build! As for the new build, all I can say is...

WOW! It loads *noticeably* faster (debug loads in approx. 4 seconds, or 1 bounce vs. 4-5) and the CPU load when running wxPython has gotten much, much better! (Down to 20% from 50% when actively using, for example, wxStyledTextCtrl... which now is behaving quite nicely! 5-8% CPU usage when idle - approx. same as MS and Dreamweaver. Not bad at all!) And I have to keep reminding myself - I'm running in *debug* mode! Congrats to you and the wxMac crew, this is a major upgrade - and you haven't gotten anywhere close to finishing wxPython 2.5/3.0! I'm going to be doing more than testing with this new version - I'll probably set it up as my primary build, provided it is not crashing excessively. =)

However, I do have one problem with my build. :wink: demo/demo.py loads the splash screen and then shuts down. No crash, no errors, it just shuts down as if all it was supposed to do was show the splash screen. As you are probably aware from my comments above, I am able to run the demos separately and they load and work just fine - so I'm not sure what is going on here. My checkout was from approx. 2-3 days ago - if I do an update, do I need to specify -r wxPy_newswig each time?

Also, one thing you might want to add to the (excellent, BTW) devel build notes is that, at least on Panther, I needed to set SWIG_LIB to /opt/swig/lib/swig1.3 for it to work. I assume this doesn't happen if you build and install to /usr/local, but I think the whole /opt build notes are a good idea.

Probably this weekend if I can get the demo completely up and running, I'll give it a thorough test. Any idea how long until there is a 2.5.1 release, for wxWin and wxPython? I'll be happy to make a Panther build and post it.

BTW, I've gotten success reports (and no complaints) on my latest Panther build so I'm going to post it soon to SF. I'll send you a note when its ready.

Thanks,

Kevin

···

On Nov 10, 2003, at 10:24 AM, Robin Dunn wrote:

Kevin Ollivier wrote:

Hi all,
Thanks to some help from Robin, I've gotten further on my quest to compile SWIG. Now, however, I'm getting strange errors that seem to indicate that it is not linking against the Python lib (or TCL, or Perl, etc.) when building the libswig<lang> library. This is baffling me... I don't think it could be because I'm on Panther... If no one here has seen this before, I'll post this over on the SWIG group. Here's the sample output for Python (I manually skipped Tcl and Perl although they both give similar errors):

I have the same errors on OS X 10.2 with autotools from fink, and Dave B. from SWIG mentioned it over the weekend that he is working on figuring out the problem.

Since wxPython doesn't need the swig runtime library (it's included in the wxPython build as libpy.c) I just ignore this error and just do a "make install". The swig executable and the rest of the swig lib will be installed and then you'll get this error again as it tries again to build the runtime shared libs, but everything I need has already been installed so it is okay.

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwindows.org

Kevin Ollivier wrote:

Hi Robin,

Thanks! You are, as always, right. <G>

My kids might disagree with you on that! <wink>

I now have a working development build! As for the new build, all I can say is...

WOW! It loads *noticeably* faster (debug loads in approx. 4 seconds, or 1 bounce vs. 4-5) and the CPU load when running wxPython has gotten much, much better! (Down to 20% from 50% when actively using, for example, wxStyledTextCtrl... which now is behaving quite nicely! 5-8% CPU usage when idle - approx. same as MS and Dreamweaver. Not bad at all!) And I have to keep reminding myself - I'm running in *debug* mode! Congrats to you and the wxMac crew, this is a major upgrade - and you haven't gotten anywhere close to finishing wxPython 2.5/3.0! I'm going to be doing more than testing with this new version - I'll probably set it up as my primary build, provided it is not crashing excessively. =)

That's good to hear. It's kinda hard for me to get a grasp on the improvements as I've been seeing them come in baby steps, while you got it all in one giant leap.

However, I do have one problem with my build. :wink: demo/demo.py loads the splash screen and then shuts down. No crash, no errors, it just shuts down as if all it was supposed to do was show the splash screen.

Well, what do you know... It's happening to me too, I wonder when that started... (I usually run the individual demo samples too.) I'll try to figure this out soon.

As you are probably aware from my comments above, I am able to run the demos separately and they load and work just fine - so I'm not sure what is going on here. My checkout was from approx. 2-3 days ago - if I do an update, do I need to specify -r wxPy_newswig each time?

No the tag is "sticky" so it will stay with the files in your workspace until you remove it with a "cvs update -A".

Also, one thing you might want to add to the (excellent, BTW) devel build notes is that, at least on Panther, I needed to set SWIG_LIB to /opt/swig/lib/swig1.3 for it to work. I assume this doesn't happen if you build and install to /usr/local, but I think the whole /opt build notes are a good idea.

Strange. I don't have to do that on any of my build systems. I thought that swig's build encoded the --prefix within the executable. What do you get if you run "/opt/swig/bin/swig -swiglib" without the env var set?

Probably this weekend if I can get the demo completely up and running, I'll give it a thorough test. Any idea how long until there is a 2.5.1 release, for wxWin and wxPython?

I'll be happy to make a Panther build and post it.

Cool. Hopefully I'll be getting a new Mac soon that I'll put Panther on. (I want to keep both for a while so I can still make Jaguar builds too without possibly tainting a Panther install with other Pythons and tools...)

BTW, I've gotten success reports (and no complaints) on my latest Panther build so I'm going to post it soon to SF. I'll send you a note when its ready.

Good. Go ahead and upload it to SF's incoming dir and I'll move it into the wxPython project files when you give me the signal.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Hi Robin,

Kevin Ollivier wrote:

Hi Robin,
Thanks! You are, as always, right. <G>

My kids might disagree with you on that! <wink>

:slight_smile: I know the feeling. I have a hard time convincing my wife that I'm right about *anything*. :wink:

I now have a working development build! As for the new build, all I can say is...
WOW! It loads *noticeably* faster (debug loads in approx. 4 seconds, or 1 bounce vs. 4-5) and the CPU load when running wxPython has gotten much, much better! (Down to 20% from 50% when actively using, for example, wxStyledTextCtrl... which now is behaving quite nicely! 5-8% CPU usage when idle - approx. same as MS and Dreamweaver. Not bad at all!) And I have to keep reminding myself - I'm running in *debug* mode! Congrats to you and the wxMac crew, this is a major upgrade - and you haven't gotten anywhere close to finishing wxPython 2.5/3.0! I'm going to be doing more than testing with this new version - I'll probably set it up as my primary build, provided it is not crashing excessively. =)

That's good to hear. It's kinda hard for me to get a grasp on the improvements as I've been seeing them come in baby steps, while you got it all in one giant leap.

However, I do have one problem with my build. :wink: demo/demo.py loads the splash screen and then shuts down. No crash, no errors, it just shuts down as if all it was supposed to do was show the splash screen.

Well, what do you know... It's happening to me too, I wonder when that started... (I usually run the individual demo samples too.) I'll try to figure this out soon.

BTW, I looked at this a bit more - it looks like the OnClose handler is not firing. I put some print statements in there and they aren't spitting out. Also, if I comment out the splash screen and simply start the demo right away, it starts up fine. BTW, when I load the demo it does still start faster, but it's not as significant as I first noticed.

After checking the demo, it is a bit of a mixed bag. =) The wxNotebook control is looking *much* better on 10.3 but there are issues with buttons and other things appearing at the top-left of the screen. One thing I notice is that any number of controls are drawing to the screen before they are positioned by the sizer, and that is probably impacting performance as well. I'll try and give this a more serious look over the weekend.

As you are probably aware from my comments above, I am able to run the demos separately and they load and work just fine - so I'm not sure what is going on here. My checkout was from approx. 2-3 days ago - if I do an update, do I need to specify -r wxPy_newswig each time?

No the tag is "sticky" so it will stay with the files in your workspace until you remove it with a "cvs update -A".

Also, one thing you might want to add to the (excellent, BTW) devel build notes is that, at least on Panther, I needed to set SWIG_LIB to /opt/swig/lib/swig1.3 for it to work. I assume this doesn't happen if you build and install to /usr/local, but I think the whole /opt build notes are a good idea.

Strange. I don't have to do that on any of my build systems. I thought that swig's build encoded the --prefix within the executable. What do you get if you run "/opt/swig/bin/swig -swiglib" without the env var set?

/usr/local/lib/swig1.3

I saw a bug report filed on SF Nov. 20th about this problem, so it seems that I'm not the only one running into it. Strange that it only affects some machines though...

Probably this weekend if I can get the demo completely up and running, I'll give it a thorough test. Any idea how long until there is a 2.5.1 release, for wxWin and wxPython?

Hmmm.... A reply of complete silence. This isn't good. <G> (j/k - it looks like you made space to write something then forgot =)

I'll be happy to make a Panther build and post it.

Cool. Hopefully I'll be getting a new Mac soon that I'll put Panther on. (I want to keep both for a while so I can still make Jaguar builds too without possibly tainting a Panther install with other Pythons and tools...)

Ok, I gotta ask - a G5? =)

BTW, I've gotten success reports (and no complaints) on my latest Panther build so I'm going to post it soon to SF. I'll send you a note when its ready.

Good. Go ahead and upload it to SF's incoming dir and I'll move it into the wxPython project files when you give me the signal.

It's ready for you!

Thanks,

Kevin

···

On Nov 10, 2003, at 4:00 PM, Robin Dunn wrote:

Kevin Ollivier wrote:

However, I do have one problem with my build. :wink: demo/demo.py loads the splash screen and then shuts down. No crash, no errors, it just shuts down as if all it was supposed to do was show the splash screen.

Well, what do you know... It's happening to me too, I wonder when that started... (I usually run the individual demo samples too.) I'll try to figure this out soon.

BTW, I looked at this a bit more - it looks like the OnClose handler is not firing. I put some print statements in there and they aren't spitting out. Also, if I comment out the splash screen and simply start the demo right away, it starts up fine.

Thanks for the extra info. I approached it a little differently but that confirms what I am seeing. Now I just need to figure out *why*.

After checking the demo, it is a bit of a mixed bag. =) The wxNotebook control is looking *much* better on 10.3 but there are issues with buttons and other things appearing at the top-left of the screen. One thing I notice is that any number of controls are drawing to the screen before they are positioned by the sizer, and that is probably impacting performance as well. I'll try and give this a more serious look over the weekend.

I remember Stefan mentionoing something about this, but I don't remember details. Also, I've sometimes seen it do that in 2.4...

Probably this weekend if I can get the demo completely up and running, I'll give it a thorough test. Any idea how long until there is a 2.5.1 release, for wxWin and wxPython?

Hmmm.... A reply of complete silence. This isn't good. <G> (j/k - it looks like you made space to write something then forgot =)

Oops, sorry. I'm not sure when an official wxWin 2.5.1 is going to happen, it was supposed to be a couple weeks ago. For wxPython I'm driving towards having a preview release ASAP, probably within a few weeks. The amount of time after that for a real release will depend on how the preview goes.

Cool. Hopefully I'll be getting a new Mac soon that I'll put Panther on. (I want to keep both for a while so I can still make Jaguar builds too without possibly tainting a Panther install with other Pythons and tools...)

Ok, I gotta ask - a G5? =)

I wish I could justify that. Instead I'm looking to get a fast dual processor G4 with extra RAM from ebay, still under Apple warranty, at about 2/3 the cost of a single processor G5.

BTW, I've gotten success reports (and no complaints) on my latest Panther build so I'm going to post it soon to SF. I'll send you a note when its ready.

Good. Go ahead and upload it to SF's incoming dir and I'll move it into the wxPython project files when you give me the signal.

It's ready for you!

Got it. Now I need to update the web page...

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

[snip]

After checking the demo, it is a bit of a mixed bag. =) The wxNotebook control is looking *much* better on 10.3 but there are issues with buttons and other things appearing at the top-left of the screen. One thing I notice is that any number of controls are drawing to the screen before they are positioned by the sizer, and that is probably impacting performance as well. I'll try and give this a more serious look over the weekend.

I remember Stefan mentionoing something about this, but I don't remember details. Also, I've sometimes seen it do that in 2.4...

I'll try and take a look at it this weekend. I'd like to see about getting some of these visual glitches fixed once and for good. =)

Also, I noticed that the demo is particularly sluggish when compared with other wxPython scripts/apps. Non-native scroll windows in particular are sluggish at rendering and scrolling both. (Is wxStyledTextCtrl drawn/rendered with wxWindows code?) I'm really starting to think the issue is window buffering and use of QuickDraw rather than Quartz.

Probably this weekend if I can get the demo completely up and running, I'll give it a thorough test. Any idea how long until there is a 2.5.1 release, for wxWin and wxPython?

Hmmm.... A reply of complete silence. This isn't good. <G> (j/k - it looks like you made space to write something then forgot =)

Oops, sorry. I'm not sure when an official wxWin 2.5.1 is going to happen, it was supposed to be a couple weeks ago. For wxPython I'm driving towards having a preview release ASAP, probably within a few weeks. The amount of time after that for a real release will depend on how the preview goes.

Ah, that's good to know. =)

Cool. Hopefully I'll be getting a new Mac soon that I'll put Panther on. (I want to keep both for a while so I can still make Jaguar builds too without possibly tainting a Panther install with other Pythons and tools...)

Ok, I gotta ask - a G5? =)

I wish I could justify that. Instead I'm looking to get a fast dual processor G4 with extra RAM from ebay, still under Apple warranty, at about 2/3 the cost of a single processor G5.

Ah well, we can dream, can't we? (or go to the Apple store and play with it for hours. :slight_smile:

Thanks,

Kevin

···

On Nov 10, 2003, at 5:41 PM, Robin Dunn wrote:

Hi Robin,

[snip]

After checking the demo, it is a bit of a mixed bag. =) The wxNotebook control is looking *much* better on 10.3 but there are issues with buttons and other things appearing at the top-left of the screen. One thing I notice is that any number of controls are drawing to the screen before they are positioned by the sizer, and that is probably impacting performance as well. I'll try and give this a more serious look over the weekend.

I remember Stefan mentionoing something about this, but I don't remember details. Also, I've sometimes seen it do that in 2.4...

I'll try and take a look at it this weekend. I'd like to see about getting some of these visual glitches fixed once and for good. =)

Also, I noticed that the demo is particularly sluggish when compared with other wxPython scripts/apps. Non-native scroll windows in particular are sluggish at rendering and scrolling both. (Is wxStyledTextCtrl drawn/rendered with wxWindows code?) I'm really starting to think the issue is window buffering and use of QuickDraw rather than Quartz.

Answering myself here =), I did some more looking into this and it seems like the modifications to scrlwing.cpp in the AOL patch may address this issue among some other things. Simon Fraser said there were some performance issues they worked around with redraws happening too often.

That leads me to a question. Would you mind (so long as I kept track) if I applied patches from the AOL code to the wxPython tree I have here? I'm certainly not planning on applying the whole thing, and I don't think that's even possible. At this point, I think one needs to actually go through the code and audit it - seeing what does apply and possibly even applying it manually. I'll ask again about this on wxDev, but when I asked about splitting up the work and making a page to keep track of which "sub-patches" have been made/applied from the AOL patch, I got no response.

In this case, however, the scrlwing.cpp fixes still seem relevant and could give us a performance boost, as well as address a clipping issue that occurs when keyboard scrolling through items. Another one I have a major interest in is the wheel mouse code, as I do have a wheel mouse and I do work on wxMozilla, and I've gotten kinda used to wheel scrolling, so... :wink: There are a couple other fixes I know I want put into there, and I particularly want to see (and maybe apply) the areas of their patch that address Mozilla drawing issues on Mac. And there are several other fixes that are in there that I know are still applicable, because I even considered writing the code for them myself. <G> (i.e. the open/save dialogs were not OS X aware last time I checked - they would not see 'bundles' properly, among other things. They have the Aqua look, but it's really the OS 9 version of the dialog.)

Thanks,

Kevin

···

On Nov 10, 2003, at 6:52 PM, Kevin Ollivier wrote:

On Nov 10, 2003, at 5:41 PM, Robin Dunn wrote:

Kevin Ollivier wrote:

Hi Robin,

Answering myself here =), I did some more looking into this and it seems like the modifications to scrlwing.cpp in the AOL patch may address this issue among some other things. Simon Fraser said there were some performance issues they worked around with redraws happening too often.

That leads me to a question. Would you mind (so long as I kept track) if I applied patches from the AOL code to the wxPython tree I have here?

I don't mind at all what you do with your personal copy of the code. (The license lets you do almost anything you want! :wink: )

Seriously though, I think it would be a good idea to merge those parts you are interested in working on and then making new patches for 2.5 for them. (If you're meaning in your 2.4 tree then we'll probably want to be a little cautious about which ones are put into any releases...)

The AOL patch has two things going against it: It is from a very old version of the source tree, and it is many fixes/features in a single patch. So any work that is done to split it into individual patches for each fix/feature and to update them for the 2.5 source will go a long way towards helping whoever will end up applying the patch. Plus your doing some independent verification of each part of the patch you work on will also help save lots of his time.

I'm certainly not planning on applying the whole thing, and I don't think that's even possible. At this point, I think one needs to actually go through the code and audit it - seeing what does apply and possibly even applying it manually. I'll ask again about this on wxDev, but when I asked about splitting up the work and making a page to keep track of which "sub-patches" have been made/applied from the AOL patch, I got no response.

I thought there was... Anyway, the AOL patch is an elephant and the only way to consume it is to divide it into bite-sized chunks.

BTW, in your 2.5 build please check the value of wxEVT_CLOSE_WINDOW. If it is the same problem I am seeing then it will incorrectly be zero and that is why using it for binding EVT_CLOSE is not working. In my case most of the wxEVT_ "constants" are not initialized by the time they are used to put a value into the python module. (This is the static initializer problem I wrote about in wx-dev.) It looks like I can write a SWIG typemap to work around the problem though.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Hi Robin,

Seriously though, I think it would be a good idea to merge those parts you are interested in working on and then making new patches for 2.5 for them. (If you're meaning in your 2.4 tree then we'll probably want to be a little cautious about which ones are put into any releases...)

I was considering putting some bug-fix patches into 2.4 (specifically the scrlwing fixes), but I don't think it's essential. In fact, with some of the improvements in 2.5 it might be best to just work on getting that to be the best that it can be. The fixes are small enough that if they work fine and bring enough of a performance increase, we can always roll them back into 2.4.

The AOL patch has two things going against it: It is from a very old version of the source tree, and it is many fixes/features in a single patch. So any work that is done to split it into individual patches for each fix/feature and to update them for the 2.5 source will go a long way towards helping whoever will end up applying the patch. Plus your doing some independent verification of each part of the patch you work on will also help save lots of his time.

Yeah, I figure that it's easier for me to test code than to write it from scratch (esp. platform specific stuff), so this is probably a good use of my time. Plus, I have a vested interest in seeing several of these patches make it into wxWindows - I have a new release of EClass coming soon and if at all possible, I want it to support Mozilla browsing and editing on Mac! (This is actually why I was asking your opinion - because I wanted to see some of those patches make it into the official wxPython distribution at least, but hopefully wxWindows core too.)

I'm certainly not planning on applying the whole thing, and I don't think that's even possible. At this point, I think one needs to actually go through the code and audit it - seeing what does apply and possibly even applying it manually. I'll ask again about this on wxDev, but when I asked about splitting up the work and making a page to keep track of which "sub-patches" have been made/applied from the AOL patch, I got no response.

I thought there was... Anyway, the AOL patch is an elephant and the only way to consume it is to divide it into bite-sized chunks.

I couldn't find anything in the mailing list, but I do know there was a discussion about it. What I'll do is make a couple small patches, i.e. the performance fixes, and I'll send a note asking if they want it and if there's anyplace where I can mark it so that they know it's been applied. I figure I'll get a concrete answer one way or another on that one. =)

BTW, in your 2.5 build please check the value of wxEVT_CLOSE_WINDOW. If it is the same problem I am seeing then it will incorrectly be zero and that is why using it for binding EVT_CLOSE is not working. In my case most of the wxEVT_ "constants" are not initialized by the time they are used to put a value into the python module. (This is the static initializer problem I wrote about in wx-dev.) It looks like I can write a SWIG typemap to work around the problem though.

Yes, that's what I'm getting for wxEVT_CLOSE_WINDOW too.

Thanks,

Kevin

···

On Nov 11, 2003, at 9:47 AM, Robin Dunn wrote:

Just FYI, SWIG cvs as of yesterday should build out of the box on OS X. It does on my Jaguar box with updated autotools from fink, and Dave B. (Mr. SWIG) says it does on his Panther box too.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!