-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failed build #67
Comments
Hi, this is a false positive, your gcc version is probably too old to notice that this path cant happen. Can you try building either optimised instead of debug, or with clang? |
My GCC version is 10.2.0, but works with clang I have a stupid question. I thought that GDK is the same as a pack of greenaddresses for Python 3, but not (?). I built "Java and Python wrappers", but Green CLI does not detect it as a pack of greenaddresses. What should I do?
|
I'm confused by what you are trying to do. To use To build your own copy of gdk, use Make sure you know which venv you are working in when installing different libraries for different purposes. |
Yep, but it's for outdated version of Python. On Debian you have Python 3.8, the newest version is 3.9, but GDK repository have 3.7 only.
So I try to build gdk for Python to use Green CLI, but it's very ... hard? Well, I should use Python 3.7 probably and binaries. |
OK, this should be fixed fairly soon by the adoption of manylinux support from libwally.
Please download the master branch and try Assuming the wheel file is found you can pip install it into your green-cli virtualenv and remove it from the requirements.txt file. |
@jgriffiths Thanks for helping :P But maybe something need to be fixed in code (or what should I do). Doesn't work with 0.0.35 and master branch
|
@IntinteDAO It seems that the python dependency has not attempted to link the python library, which gdk currently expects to be able to do. This is in fact the 'proper' way to build python modules, and is required for manylinux support (e.g. pypy releases of gdk). But currently the build system expects to link the shared library with no undefined symbols, so that the library can be used from both python and C/C++. In your case I don't know if thats because your version of meson combined with our quite non-standard module building is the issue, or because you don't have the dependencies installed where meson expects them. Can you apply #71 to your master branch and re-try the build? If that fails please pastebin the full build output including the command line you used and link it here, thanks. |
I just download your fork of gdk and change branch, but should be ok. If you want access to my server (to check it manually) I can give you |
Thanks for that - can you pastebin the |
https://gmclan.org/uploader/18941/meson_log.txt Here you go |
Hi @IntinteDAO I've updated #71 to hopefully ensure that the dependency includes libpython, the lack of which being the cause of your build failure. Can you try the updated PR? |
The problem is probably the same, but I have libpython3.8-dev and libpython3.8 in my system. Maybe some Python3.8 regression?
|
@IntinteDAO seems to be mesonbuild/meson#5629 - I've pushed an attempted work around to that PR if you could try again? |
the travis OSX build moved to python 3.9 and the updated PR fixed the same issue there, so I'm closing this as the fix should work for you too @IntinteDAO. I'll merge following code review, many thanks for your patience investigating this! |
Works! :) |
Fantastic, thanks for confirming :) |
Debian Sid. If you need any info - just ask.
The text was updated successfully, but these errors were encountered: