Building wxPython 4.0.1 in cygwin

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Building wxPython 4.0.1 in cygwin

Hamish McIntyre-Bhatty
Hi all,

I've been attempting to get a wxpython 4.0.1 build for Python 3 working under Cygwin the past few days. I am building against gtk2 and the system wxwidgets version (3.0.2). I haven't yet managed to get newer versions of wxWidgets to build, but as I found the build at https://launchpad.net/~swt-techie/+archive/ubuntu/wxpython4 works and Ubuntu 16.04 has similar dependencies, I am taking my build arguments and similar from that - and trying some of the patches, but with no success yet.

My build options for the last part of the build are: "python3 build.py build_py --use_syswx --gtk2" (after running dox etg --nodoc and sip)

I've gotten fairly far along now, but I keep running into an error where when sip_corewxAcceleratorTable.cpp is compiled:

I get an extremely long list of errors about classes being redefined or having multiple definition (example: wx/object.h:422:7: error: redefinition of 'class wxClassInfo' ), and the build fails. I can provide more information and attach a complete log if required.

Does anyone have any ideas why this might be happening?

Hamish McIntyre-Bhatty

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/9c295742-750e-4b1e-9f24-3e514a6a1068%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Building wxPython 4.0.1 in cygwin

Robin Dunn


On Saturday, May 25, 2019 at 3:42:14 AM UTC-7, Hamish McIntyre-Bhatty wrote:
Hi all,

I've been attempting to get a wxpython 4.0.1 build for Python 3 working under Cygwin the past few days. I am building against gtk2 and the system wxwidgets version (3.0.2). I haven't yet managed to get newer versions of wxWidgets to build, but as I found the build at <a href="https://launchpad.net/~swt-techie/+archive/ubuntu/wxpython4" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Flaunchpad.net%2F~swt-techie%2F%2Barchive%2Fubuntu%2Fwxpython4\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHetOELTa_QQcjvqkqY-pieAMV6NQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Flaunchpad.net%2F~swt-techie%2F%2Barchive%2Fubuntu%2Fwxpython4\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHetOELTa_QQcjvqkqY-pieAMV6NQ&#39;;return true;">https://launchpad.net/~swt-techie/+archive/ubuntu/wxpython4 works and Ubuntu 16.04 has similar dependencies, I am taking my build arguments and similar from that - and trying some of the patches, but with no success yet.

My build options for the last part of the build are: "python3 build.py build_py --use_syswx --gtk2" (after running dox etg --nodoc and sip)

I've gotten fairly far along now, but I keep running into an error where when sip_corewxAcceleratorTable.cpp is compiled:

I get an extremely long list of errors about classes being redefined or having multiple definition (example: wx/object.h:422:7: error: redefinition of 'class wxClassInfo' ), and the build fails. I can provide more information and attach a complete log if required.

Does anyone have any ideas why this might be happening?

Unless you've hunted them all down and fixed them there are likely a number of places in build.py and supporting scripts that are going to assume a win32/64 build on Windows, not a build using a gtk port. Perhaps there are some unexpected flags being passed to the compiler do to confusion about the port that is resulting in more than one version of that class being defined.

--
Robin

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/bfd67cb3-c2e5-4601-8bca-c5e350bd4724%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Building wxPython 4.0.1 in cygwin

Hamish McIntyre-Bhatty
Thanks for the advice.

It looks like it's trying to include from both ext/wxWidgets/ and /usr/include/wx-3.0, and the files are conflicting as you said.

However, I can't figure out where the build options are generated so I can resolve this and try to only include from /usr/include/wx-3.0, could you give me a hint please? :)

Hamish

On Sunday, May 26, 2019 at 1:46:16 AM UTC+1, Robin Dunn wrote:


On Saturday, May 25, 2019 at 3:42:14 AM UTC-7, Hamish McIntyre-Bhatty wrote:
Hi all,

I've been attempting to get a wxpython 4.0.1 build for Python 3 working under Cygwin the past few days. I am building against gtk2 and the system wxwidgets version (3.0.2). I haven't yet managed to get newer versions of wxWidgets to build, but as I found the build at <a href="https://launchpad.net/~swt-techie/+archive/ubuntu/wxpython4" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Flaunchpad.net%2F~swt-techie%2F%2Barchive%2Fubuntu%2Fwxpython4\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHetOELTa_QQcjvqkqY-pieAMV6NQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Flaunchpad.net%2F~swt-techie%2F%2Barchive%2Fubuntu%2Fwxpython4\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHetOELTa_QQcjvqkqY-pieAMV6NQ&#39;;return true;">https://launchpad.net/~swt-techie/+archive/ubuntu/wxpython4 works and Ubuntu 16.04 has similar dependencies, I am taking my build arguments and similar from that - and trying some of the patches, but with no success yet.

My build options for the last part of the build are: "python3 build.py build_py --use_syswx --gtk2" (after running dox etg --nodoc and sip)

I've gotten fairly far along now, but I keep running into an error where when sip_corewxAcceleratorTable.cpp is compiled:

I get an extremely long list of errors about classes being redefined or having multiple definition (example: wx/object.h:422:7: error: redefinition of 'class wxClassInfo' ), and the build fails. I can provide more information and attach a complete log if required.

Does anyone have any ideas why this might be happening?

Unless you've hunted them all down and fixed them there are likely a number of places in build.py and supporting scripts that are going to assume a win32/64 build on Windows, not a build using a gtk port. Perhaps there are some unexpected flags being passed to the compiler do to confusion about the port that is resulting in more than one version of that class being defined.

--
Robin

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/ba0c6213-6029-4cf4-9843-8faf3da534f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Building wxPython 4.0.1 in cygwin

Hamish McIntyre-Bhatty
On Thursday, May 30, 2019 at 12:19:05 PM UTC+1, Hamish McIntyre-Bhatty wrote:
Thanks for the advice.

It looks like it's trying to include from both ext/wxWidgets/ and /usr/include/wx-3.0, and the files are conflicting as you said.

However, I can't figure out where the build options are generated so I can resolve this and try to only include from /usr/include/wx-3.0, could you give me a hint please? :)

Hamish

On Sunday, May 26, 2019 at 1:46:16 AM UTC+1, Robin Dunn wrote:


On Saturday, May 25, 2019 at 3:42:14 AM UTC-7, Hamish McIntyre-Bhatty wrote:
Hi all,

I've been attempting to get a wxpython 4.0.1 build for Python 3 working under Cygwin the past few days. I am building against gtk2 and the system wxwidgets version (3.0.2). I haven't yet managed to get newer versions of wxWidgets to build, but as I found the build at <a href="https://launchpad.net/~swt-techie/+archive/ubuntu/wxpython4" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Flaunchpad.net%2F~swt-techie%2F%2Barchive%2Fubuntu%2Fwxpython4\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHetOELTa_QQcjvqkqY-pieAMV6NQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Flaunchpad.net%2F~swt-techie%2F%2Barchive%2Fubuntu%2Fwxpython4\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHetOELTa_QQcjvqkqY-pieAMV6NQ&#39;;return true;">https://launchpad.net/~swt-techie/+archive/ubuntu/wxpython4 works and Ubuntu 16.04 has similar dependencies, I am taking my build arguments and similar from that - and trying some of the patches, but with no success yet.

My build options for the last part of the build are: "python3 build.py build_py --use_syswx --gtk2" (after running dox etg --nodoc and sip)

I've gotten fairly far along now, but I keep running into an error where when sip_corewxAcceleratorTable.cpp is compiled:

I get an extremely long list of errors about classes being redefined or having multiple definition (example: wx/object.h:422:7: error: redefinition of 'class wxClassInfo' ), and the build fails. I can provide more information and attach a complete log if required.

Does anyone have any ideas why this might be happening?

Unless you've hunted them all down and fixed them there are likely a number of places in build.py and supporting scripts that are going to assume a win32/64 build on Windows, not a build using a gtk port. Perhaps there are some unexpected flags being passed to the compiler do to confusion about the port that is resulting in more than one version of that class being defined.

--
Robin


Update: Looks like it's being included when SIP generates the files for example this can be found at the top of sip_core_ScrolledWindowsBase.cpp:

"
#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/scrolwin.h>
#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/window.h>
#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/gdicmn.h>
"

And so on. Is there a way I can configure SIP to avoid this?

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/ff7b4b3c-4525-4e44-b142-a800ebe60362%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Building wxPython 4.0.1 in cygwin

Robin Dunn

On Thursday, May 30, 2019 at 4:29:42 AM UTC-7, Hamish McIntyre-Bhatty wrote:

Update: Looks like it's being included when SIP generates the files for example this can be found at the top of sip_core_ScrolledWindowsBase.cpp:

"
#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/scrolwin.h>
#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/window.h>
#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/gdicmn.h>
"

And so on. Is there a way I can configure SIP to avoid this?

I think the problem is happening before the SIP step. To verify, look in the generated files in sip/gen/*.sip. They probably already have the full path instead of just <wx/whatever.h> inside the generated %TypeHeaderCode blocks.  If so, then it's likely the 'dox' step that is incorrect. The *.sip files are generated by the 'etg' step, but for the most part it just pulls the include file paths directly from the XML files produced by doxygen.

HTH,
Robin


 

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/c2a69827-de91-42bf-a06b-7c775ae31b04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Building wxPython 4.0.1 in cygwin

Hamish McIntyre-Bhatty


On Thursday, May 30, 2019 at 6:45:26 PM UTC+1, Robin Dunn wrote:

On Thursday, May 30, 2019 at 4:29:42 AM UTC-7, Hamish McIntyre-Bhatty wrote:

Update: Looks like it's being included when SIP generates the files for example this can be found at the top of sip_core_ScrolledWindowsBase.cpp:

"
#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/scrolwin.h>
#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/window.h>
#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/gdicmn.h>
"

And so on. Is there a way I can configure SIP to avoid this?

I think the problem is happening before the SIP step. To verify, look in the generated files in sip/gen/*.sip. They probably already have the full path instead of just <wx/whatever.h> inside the generated %TypeHeaderCode blocks.  If so, then it's likely the 'dox' step that is incorrect. The *.sip files are generated by the 'etg' step, but for the most part it just pulls the include file paths directly from the XML files produced by doxygen.

HTH,
Robin

Yes, you're right, the %TypeHeaderCode blocks also have this issue.

What should I check next? I'm not very familiar with wxPython's source tree and build system, so I feel I'm getting way out of my depth now!

Hamish
 

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/2dfe9cc1-02d3-4099-864e-e284c4b41f8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Building wxPython 4.0.1 in cygwin

Robin Dunn

On Monday, June 10, 2019 at 10:11:12 AM UTC-7, Hamish McIntyre-Bhatty wrote:


On Thursday, May 30, 2019 at 6:45:26 PM UTC+1, Robin Dunn wrote:

On Thursday, May 30, 2019 at 4:29:42 AM UTC-7, Hamish McIntyre-Bhatty wrote:

Update: Looks like it's being included when SIP generates the files for example this can be found at the top of sip_core_ScrolledWindowsBase.cpp:

"
#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/scrolwin.h>
#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/window.h>
#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/gdicmn.h>
"

And so on. Is there a way I can configure SIP to avoid this?

I think the problem is happening before the SIP step. To verify, look in the generated files in sip/gen/*.sip. They probably already have the full path instead of just <wx/whatever.h> inside the generated %TypeHeaderCode blocks.  If so, then it's likely the 'dox' step that is incorrect. The *.sip files are generated by the 'etg' step, but for the most part it just pulls the include file paths directly from the XML files produced by doxygen.

HTH,
Robin

Yes, you're right, the %TypeHeaderCode blocks also have this issue.

What should I check next? I'm not very familiar with wxPython's source tree and build system, so I feel I'm getting way out of my depth now!


If you're working from a wxPython tarball (rather than a git checkout, for example) and you don't need to make changes to the etg scripts or other code gen inputs, then you shouldn't need to run the code generation steps as it's all there already. So I would try just the "python3 build.py build_py --use_syswx --gtk2" command you mentioned in the first message.

If you do need to make changes that require the code to be regenerated then you'll want to look at how build.py sets things up to run the regen.sh script, which is where doxygen is run. IIRC, Doxygen makes some assumptions about the location of the header files based on the current working directory, or something like that. 

--
Robin

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/1b0b6a05-1e45-4235-893e-cbc75ce5ee76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Building wxPython 4.0.1 in cygwin

Hamish
Thanks for the suggestion :)

I tried that, and I got this error:



According to this post
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892237
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892237>  , this bug has
already been fixed, so I will now try the latest version of wxPython 4.



--
Sent from: http://wxpython-users.1045709.n5.nabble.com/

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/1561668086961-0.post%40n5.nabble.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Building wxPython 4.0.1 in cygwin

Hamish
In reply to this post by Robin Dunn
SO, I tried with wxPython 4.0.6 and Python 3.6 and 3.7, but in both cases I
get this error. Apologies in advance because this is long, but I don't know
what the relevant parts are.



Any ideas?



--
Sent from: http://wxpython-users.1045709.n5.nabble.com/

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/1561668565877-0.post%40n5.nabble.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Building wxPython 4.0.1 in cygwin

Hamish McIntyre-Bhatty
In reply to this post by Robin Dunn


On Monday, June 10, 2019 at 11:18:23 PM UTC+1, Robin Dunn wrote:

On Monday, June 10, 2019 at 10:11:12 AM UTC-7, Hamish McIntyre-Bhatty wrote:


On Thursday, May 30, 2019 at 6:45:26 PM UTC+1, Robin Dunn wrote:

On Thursday, May 30, 2019 at 4:29:42 AM UTC-7, Hamish McIntyre-Bhatty wrote:

Update: Looks like it's being included when SIP generates the files for example this can be found at the top of sip_core_ScrolledWindowsBase.cpp:

"
#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/scrolwin.h>
#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/window.h>
#include </home/Hamish/wxpython-build/wxPython-4.0.1/ext/wxWidgets/interface/wx/gdicmn.h>
"

And so on. Is there a way I can configure SIP to avoid this?

I think the problem is happening before the SIP step. To verify, look in the generated files in sip/gen/*.sip. They probably already have the full path instead of just <wx/whatever.h> inside the generated %TypeHeaderCode blocks.  If so, then it's likely the 'dox' step that is incorrect. The *.sip files are generated by the 'etg' step, but for the most part it just pulls the include file paths directly from the XML files produced by doxygen.

HTH,
Robin

Yes, you're right, the %TypeHeaderCode blocks also have this issue.

What should I check next? I'm not very familiar with wxPython's source tree and build system, so I feel I'm getting way out of my depth now!


If you're working from a wxPython tarball (rather than a git checkout, for example) and you don't need to make changes to the etg scripts or other code gen inputs, then you shouldn't need to run the code generation steps as it's all there already. So I would try just the "python3 build.py build_py --use_syswx --gtk2" command you mentioned in the first message.

If you do need to make changes that require the code to be regenerated then you'll want to look at how build.py sets things up to run the regen.sh script, which is where doxygen is run. IIRC, Doxygen makes some assumptions about the location of the header files based on the current working directory, or something like that. 

--
Robin


Hi Robin,

Sorry for slow reply, and for the large amount of terminal output here.

So, I tried what you suggested, and encountered the error documented here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892237. Seeing as this was fixed in a new wxPython release, I thought I'd try building 4.0.6 instead. When I tried the build_py command for that, I instead got this error, the causes of which I am uncertain:

[ 11/868] Linking build/waf/3.7/gtk2/siplib.cpython-37m-i386-cygwin.dll
[ 12/868] Compiling sip/cpp/sip_corewxMemoryBuffer.cpp
[ 15/868] Compiling sip/cpp/sip_corewxAccessible.cpp
[ 16/868] Compiling sip/cpp/sip_corewxMaximizeEvent.cpp
sip/siplib/apiversions.c.1.o: In function `sipInitAPI':
/home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/../../../../sip/siplib/apiversions.c:132: undefined reference to `PyCFunction_NewEx'
/home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/../../../../sip/siplib/apiversions.c:135: undefined reference to `PyDict_SetItemString'
sip/siplib/apiversions.c.1.o: In function `sipGetAPI':
/home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/../../../../sip/siplib/apiversions.c:189: undefined reference to `PyArg_ParseTuple'
/home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/../../../../sip/siplib/apiversions.c:199: undefined reference to `PyLong_FromLong'
/home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/../../../../sip/siplib/apiversions.c:194: undefined reference to `_imp__PyExc_ValueError'
/home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk2/../../../../sip/siplib/apiversions.c:194: undefined reference to `PyErr_Format'

And so on - the output scrolls a really long way. I do have python3-devel installed, but it sounds like it's not finding the library to link to or something. Can I specify it manually?

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/9319309f-5054-45cb-b8b1-b1d930e5b979%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Building wxPython 4.0.1 in cygwin

Robin Dunn


On Friday, June 28, 2019 at 2:07:57 AM UTC-7, Hamish wrote:
...
And so on - the output scrolls a really long way. I do have python3-devel installed, but it sounds like it's not finding the library to link to or something. Can I specify it manually?

Yes, those symbols should be loaded from the Python shared library. On Windows it explicitly links with the Python DLL to ensure they are correct. On linux and the like the symbols are already in memory and accessible when Python does the import of the extension module, so it does more of a soft link when building the extensions. My guess is that when doing a real cygwin build it (waf) is assuming it is more like the latter, but since it's windows it needs to be done like the former. That's just a guess though, you may need to dig into the builds of some other extensions and see how they're doing it for cygwin.

(Another guess) Once you find out what is needed for the link you should be able to set LDFLAGS in the environment and waf will add that to the link command lines. So you can use it to set extra -Ldir and -llib flags.

--Robin

 

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/3614c526-c7dc-4fb9-b095-ed0f739801ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Building wxPython 4.0.1 in cygwin

Hamish McIntyre-Bhatty


On Tuesday, July 2, 2019 at 4:08:04 AM UTC+1, Robin Dunn wrote:


On Friday, June 28, 2019 at 2:07:57 AM UTC-7, Hamish wrote:
...
And so on - the output scrolls a really long way. I do have python3-devel installed, but it sounds like it's not finding the library to link to or something. Can I specify it manually?

Yes, those symbols should be loaded from the Python shared library. On Windows it explicitly links with the Python DLL to ensure they are correct. On linux and the like the symbols are already in memory and accessible when Python does the import of the extension module, so it does more of a soft link when building the extensions. My guess is that when doing a real cygwin build it (waf) is assuming it is more like the latter, but since it's windows it needs to be done like the former. That's just a guess though, you may need to dig into the builds of some other extensions and see how they're doing it for cygwin.

(Another guess) Once you find out what is needed for the link you should be able to set LDFLAGS in the environment and waf will add that to the link command lines. So you can use it to set extra -Ldir and -llib flags.

--Robin

 

Thank you very much for all of your help. I'm now much closer than before, using the command:

LDFLAGS="-L/usr/lib -lpython3.7m -lX11 -lgtk-3 -lgdk-3" python3.7 build.py build_py --use_syswx --gtk3

I do eventually reach this error though, and I don't know how to fix it:

sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function `ZNK29sipwxRichTextFormattingDialog16GetContentWindowEv':
/home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk3/../../../../sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp:178: undefined reference to `
wxPropertySheetDialog::GetContentWindow() const'
sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function `ZN29sipwxRichTextFormattingDialog11AddBookCtrlEP7wxSizer'
:
/home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk3/../../../../sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp:848: undefined reference to `wxPropertySheetDialog::AddBookCtrl(wxSizer*)'
sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function `
ZN29sipwxRichTextFormattingDialog14CreateBookCtrlEv':
/home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk3/../../../../sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp:865: undefined reference to `wxPropertySheetDialog::CreateBookCtrl()'

sip
/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function `ZN29sipwxRichTextFormattingDialog13CreateButtonsEi':
/home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk3/../../../../sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp:881: undefined reference to `
wxPropertySheetDialog::CreateButtons(int)'
sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function `ZN29sipwxRichTextFormattingDialog12LayoutDialogEi'
:
/home/Hamish/wxpython-build/wxPython-4.0.6/build/waf/3.7/gtk3/../../../../sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp:899: undefined reference to `wxPropertySheetDialog::LayoutDialog(int)'
sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function `
ZN21wxPropertySheetDialogC4Ev':
/usr/include/wx-3.0/wx/generic/propdlg.h:82: undefined reference to `vtable for wxPropertySheetDialog'

/usr/include/wx-3.0/wx/generic/propdlg.h:82: undefined reference to `wxPropertySheetDialog::Init()'
sip/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function `
ZN21wxPropertySheetDialogD4Ev':
/usr/include/wx-3.0/wx/generic/propdlg.h:79: undefined reference to `vtable for wxPropertySheetDialog'

sip
/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function `ZN21wxPropertySheetDialogC4Ev':
/usr/include/wx-3.0/wx/generic/propdlg.h:82: undefined reference to `
vtable for wxPropertySheetDialog'
/usr/include/wx-3.0/wx/generic/propdlg.h:82: undefined reference to `wxPropertySheetDialog::Init()'

sip
/cpp/sip_richtextwxRichTextFormattingDialog.cpp.23.o: In function `ZN21wxPropertySheetDialogD4Ev':
/usr/include/wx-3.0/wx/generic/propdlg.h:79: undefined reference to `
vtable for wxPropertySheetDialog'
collect2: error: ld returned 1 exit status

Is my system wxwidgets too old? I might be able to build a newer one, but would be good to not do that if possible :)

Hamish

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/f5d390c0-e375-4ab3-b3b1-386a6d922457%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Building wxPython 4.0.1 in cygwin

Robin Dunn
On Tuesday, July 2, 2019 at 9:34:49 AM UTC-7, Hamish McIntyre-Bhatty wrote:
Is my system wxwidgets too old? I might be able to build a newer one, but would be good to not do that if possible :)

It's possible. What version do you have? It could also be that the wxWIdgets was not built with all options enabled.

Or, since these are linker errors then it could be another case of library flags being incorrect. If wxWidgets was built in the normal mode then the richtext code will be in a separate lib, and the wxPropertySheetDialog will be in the core library, so you'll want to ensure that both are being used when linking the richtext extension module, and that the core library comes first.  You can pass `--verbose` to the build.py command line to see the actual compile and link commands being run by waf.

--
Robin

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/fe22b9f9-cfe0-4fc9-84d1-a305f63362c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Building wxPython 4.0.1 in cygwin

Hamish McIntyre-Bhatty


On Wednesday, July 3, 2019 at 7:06:56 PM UTC+1, Robin Dunn wrote:
On Tuesday, July 2, 2019 at 9:34:49 AM UTC-7, Hamish McIntyre-Bhatty wrote:
Is my system wxwidgets too old? I might be able to build a newer one, but would be good to not do that if possible :)

It's possible. What version do you have? It could also be that the wxWIdgets was not built with all options enabled.

Or, since these are linker errors then it could be another case of library flags being incorrect. If wxWidgets was built in the normal mode then the richtext code will be in a separate lib, and the wxPropertySheetDialog will be in the core library, so you'll want to ensure that both are being used when linking the richtext extension module, and that the core library comes first.  You can pass `--verbose` to the build.py command line to see the actual compile and link commands being run by waf.

--
Robin


 It is version 3.0.3.0, as reported by wx-config.

Yes, I've been making good use of the --verbose option :). I will do some more digging - I should be able to find what the build options were because it's an official cygwin package for wxwidgets.

Hamish

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/9100492c-5a44-4a7a-b668-9923253acdfa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Building wxPython 4.0.1 in cygwin

Hamish McIntyre-Bhatty


On Friday, July 5, 2019 at 12:14:14 PM UTC+1, Hamish McIntyre-Bhatty wrote:


On Wednesday, July 3, 2019 at 7:06:56 PM UTC+1, Robin Dunn wrote:
On Tuesday, July 2, 2019 at 9:34:49 AM UTC-7, Hamish McIntyre-Bhatty wrote:
Is my system wxwidgets too old? I might be able to build a newer one, but would be good to not do that if possible :)

It's possible. What version do you have? It could also be that the wxWIdgets was not built with all options enabled.

Or, since these are linker errors then it could be another case of library flags being incorrect. If wxWidgets was built in the normal mode then the richtext code will be in a separate lib, and the wxPropertySheetDialog will be in the core library, so you'll want to ensure that both are being used when linking the richtext extension module, and that the core library comes first.  You can pass `--verbose` to the build.py command line to see the actual compile and link commands being run by waf.

--
Robin


 It is version 3.0.3.0, as reported by wx-config.

Yes, I've been making good use of the --verbose option :). I will do some more digging - I should be able to find what the build options were because it's an official cygwin package for wxwidgets.

Hamish

Looks like it was built with:

        --enable-optimise \
       
--enable-shared \
       
--enable-unicode \
       
--enable-mediactrl \
       
--disable-gtktest \
       
--disable-rpath \
       
--disable-sdltest \
       
--disable-webviewwebkit \
       
--with-expat \
       
--with-gtk=3 \
       
--without-gnomeprint --without-gnomevfs \
       
--with-libpng \
       
--with-libjpeg \
       
--with-libiconv \
       
--with-libmspack \
       
--with-libnotify \
       
--with-libtiff \
       
--with-libxpm \
       
--with-opengl \
       
--with-sdl \
       
--with-zlib


 Hamish

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/4836dc51-88af-4de1-90ae-e1038102ee52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Building wxPython 4.0.1 in cygwin

Hamish McIntyre-Bhatty


On Friday, July 5, 2019 at 12:34:27 PM UTC+1, Hamish McIntyre-Bhatty wrote:


On Friday, July 5, 2019 at 12:14:14 PM UTC+1, Hamish McIntyre-Bhatty wrote:


On Wednesday, July 3, 2019 at 7:06:56 PM UTC+1, Robin Dunn wrote:
On Tuesday, July 2, 2019 at 9:34:49 AM UTC-7, Hamish McIntyre-Bhatty wrote:
Is my system wxwidgets too old? I might be able to build a newer one, but would be good to not do that if possible :)

It's possible. What version do you have? It could also be that the wxWIdgets was not built with all options enabled.

Or, since these are linker errors then it could be another case of library flags being incorrect. If wxWidgets was built in the normal mode then the richtext code will be in a separate lib, and the wxPropertySheetDialog will be in the core library, so you'll want to ensure that both are being used when linking the richtext extension module, and that the core library comes first.  You can pass `--verbose` to the build.py command line to see the actual compile and link commands being run by waf.

--
Robin


 It is version 3.0.3.0, as reported by wx-config.

Yes, I've been making good use of the --verbose option :). I will do some more digging - I should be able to find what the build options were because it's an official cygwin package for wxwidgets.

Hamish

Looks like it was built with:

        --enable-optimise \
       
--enable-shared \
       
--enable-unicode \
       
--enable-mediactrl \
       
--disable-gtktest \
       
--disable-rpath \
       
--disable-sdltest \
       
--disable-webviewwebkit \
       
--with-expat \
       
--with-gtk=3 \
       
--without-gnomeprint --without-gnomevfs \
       
--with-libpng \
       
--with-libjpeg \
       
--with-libiconv \
       
--with-libmspack \
       
--with-libnotify \
       
--with-libtiff \
       
--with-libxpm \
       
--with-opengl \
       
--with-sdl \
       
--with-zlib


 Hamish

I had a look at the linker flags, and they are as you say, core is included before the richtext module. If I specify them manaully in the LDFLAGS variable, it still fails, so I think that that isn't the problem. I'm going to guess that I need wxWidgets 3.0.4, so I'll see if I can get that compiling.

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/wxpython-users/dad25b70-939e-4876-9330-8276a8760ea0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.