-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #301 from lrusak/python-curses
Python: build readline and curses modules
- Loading branch information
Showing
2 changed files
with
243 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
241 changes: 241 additions & 0 deletions
241
packages/lang/Python/patches/Python-2.7.11-017-link-curses-module-against-termcap.patch
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,241 @@ | ||
| diff -Naur a/Modules/_cursesmodule.c b/Modules/_cursesmodule.c | ||
| --- a/Modules/_cursesmodule.c 2015-12-05 11:47:13.000000000 -0800 | ||
| +++ b/Modules/_cursesmodule.c 2016-04-29 01:22:41.271608696 -0700 | ||
| @@ -312,7 +312,6 @@ | ||
| Window_NoArgNoReturnVoidFunction(wclear) | ||
|
|
||
| Window_OneArgNoReturnVoidFunction(idcok, int, "i;True(1) or False(0)") | ||
| -Window_OneArgNoReturnVoidFunction(immedok, int, "i;True(1) or False(0)") | ||
| Window_OneArgNoReturnVoidFunction(wtimeout, int, "i;delay") | ||
|
|
||
| Window_NoArg2TupleReturnFunction(getyx, int, "ii") | ||
| @@ -336,7 +335,6 @@ | ||
| Window_OneArgNoReturnFunction(notimeout, int, "i;True(1) or False(0)") | ||
| Window_OneArgNoReturnFunction(scrollok, int, "i;True(1) or False(0)") | ||
| Window_OneArgNoReturnFunction(winsdelln, int, "i;nlines") | ||
| -Window_OneArgNoReturnFunction(syncok, int, "i;True(1) or False(0)") | ||
|
|
||
| Window_TwoArgNoReturnFunction(mvwin, int, "ii;y,x") | ||
| Window_TwoArgNoReturnFunction(mvderwin, int, "ii;y,x") | ||
| @@ -1580,7 +1578,6 @@ | ||
| {"hline", (PyCFunction)PyCursesWindow_Hline, METH_VARARGS}, | ||
| {"idcok", (PyCFunction)PyCursesWindow_idcok, METH_VARARGS}, | ||
| {"idlok", (PyCFunction)PyCursesWindow_idlok, METH_VARARGS}, | ||
| - {"immedok", (PyCFunction)PyCursesWindow_immedok, METH_VARARGS}, | ||
| {"inch", (PyCFunction)PyCursesWindow_InCh, METH_VARARGS}, | ||
| {"insch", (PyCFunction)PyCursesWindow_InsCh, METH_VARARGS}, | ||
| {"insdelln", (PyCFunction)PyCursesWindow_winsdelln, METH_VARARGS}, | ||
| @@ -1618,7 +1615,6 @@ | ||
| {"subpad", (PyCFunction)PyCursesWindow_SubWin, METH_VARARGS}, | ||
| {"subwin", (PyCFunction)PyCursesWindow_SubWin, METH_VARARGS}, | ||
| {"syncdown", (PyCFunction)PyCursesWindow_wsyncdown, METH_NOARGS}, | ||
| - {"syncok", (PyCFunction)PyCursesWindow_syncok, METH_VARARGS}, | ||
| {"syncup", (PyCFunction)PyCursesWindow_wsyncup, METH_NOARGS}, | ||
| {"timeout", (PyCFunction)PyCursesWindow_wtimeout, METH_VARARGS}, | ||
| {"touchline", (PyCFunction)PyCursesWindow_TouchLine, METH_VARARGS}, | ||
| @@ -1693,16 +1689,6 @@ | ||
| NoArgNoReturnVoidFunction(noqiflush) | ||
|
|
||
| static PyObject * | ||
| -PyCurses_filter(PyObject *self) | ||
| -{ | ||
| - /* not checking for PyCursesInitialised here since filter() must | ||
| - be called before initscr() */ | ||
| - filter(); | ||
| - Py_INCREF(Py_None); | ||
| - return Py_None; | ||
| -} | ||
| - | ||
| -static PyObject * | ||
| PyCurses_Color_Content(PyObject *self, PyObject *args) | ||
| { | ||
| short color,r,g,b; | ||
| @@ -1772,19 +1758,6 @@ | ||
| return PyString_FromStringAndSize(&ch, 1); | ||
| } | ||
|
|
||
| -static PyObject * | ||
| -PyCurses_getsyx(PyObject *self) | ||
| -{ | ||
| - int x = 0; | ||
| - int y = 0; | ||
| - | ||
| - PyCursesInitialised; | ||
| - | ||
| - getsyx(y, x); | ||
| - | ||
| - return Py_BuildValue("(ii)", y, x); | ||
| -} | ||
| - | ||
| #ifdef NCURSES_MOUSE_VERSION | ||
| static PyObject * | ||
| PyCurses_GetMouse(PyObject *self) | ||
| @@ -1855,25 +1828,6 @@ | ||
| return PyCursesCheckERR(halfdelay(tenths), "halfdelay"); | ||
| } | ||
|
|
||
| -#ifndef STRICT_SYSV_CURSES | ||
| -/* No has_key! */ | ||
| -static PyObject * PyCurses_has_key(PyObject *self, PyObject *args) | ||
| -{ | ||
| - int ch; | ||
| - | ||
| - PyCursesInitialised; | ||
| - | ||
| - if (!PyArg_ParseTuple(args,"i",&ch)) return NULL; | ||
| - | ||
| - if (has_key(ch) == FALSE) { | ||
| - Py_INCREF(Py_False); | ||
| - return Py_False; | ||
| - } | ||
| - Py_INCREF(Py_True); | ||
| - return Py_True; | ||
| -} | ||
| -#endif /* STRICT_SYSV_CURSES */ | ||
| - | ||
| static PyObject * | ||
| PyCurses_Init_Color(PyObject *self, PyObject *args) | ||
| { | ||
| @@ -2426,26 +2380,6 @@ | ||
| #endif /* HAVE_CURSES_RESIZE_TERM */ | ||
|
|
||
| static PyObject * | ||
| -PyCurses_setsyx(PyObject *self, PyObject *args) | ||
| -{ | ||
| - int y,x; | ||
| - | ||
| - PyCursesInitialised; | ||
| - | ||
| - if (PyTuple_Size(args)!=2) { | ||
| - PyErr_SetString(PyExc_TypeError, "setsyx requires 2 arguments"); | ||
| - return NULL; | ||
| - } | ||
| - | ||
| - if (!PyArg_ParseTuple(args, "ii;y, x", &y, &x)) return NULL; | ||
| - | ||
| - setsyx(y,x); | ||
| - | ||
| - Py_INCREF(Py_None); | ||
| - return Py_None; | ||
| -} | ||
| - | ||
| -static PyObject * | ||
| PyCurses_Start_Color(PyObject *self) | ||
| { | ||
| int code; | ||
| @@ -2539,18 +2473,6 @@ | ||
| } | ||
|
|
||
| static PyObject * | ||
| -PyCurses_TypeAhead(PyObject *self, PyObject *args) | ||
| -{ | ||
| - int fd; | ||
| - | ||
| - PyCursesInitialised; | ||
| - | ||
| - if (!PyArg_ParseTuple(args,"i;fd",&fd)) return NULL; | ||
| - | ||
| - return PyCursesCheckERR(typeahead( fd ), "typeahead"); | ||
| -} | ||
| - | ||
| -static PyObject * | ||
| PyCurses_UnCtrl(PyObject *self, PyObject *args) | ||
| { | ||
| PyObject *temp; | ||
| @@ -2594,25 +2516,6 @@ | ||
| return PyCursesCheckERR(ungetch(ch), "ungetch"); | ||
| } | ||
|
|
||
| -static PyObject * | ||
| -PyCurses_Use_Env(PyObject *self, PyObject *args) | ||
| -{ | ||
| - int flag; | ||
| - | ||
| - switch(PyTuple_Size(args)) { | ||
| - case 1: | ||
| - if (!PyArg_ParseTuple(args,"i;True(1), False(0)",&flag)) | ||
| - return NULL; | ||
| - break; | ||
| - default: | ||
| - PyErr_SetString(PyExc_TypeError, "use_env requires 1 argument"); | ||
| - return NULL; | ||
| - } | ||
| - use_env(flag); | ||
| - Py_INCREF(Py_None); | ||
| - return Py_None; | ||
| -} | ||
| - | ||
| #ifndef STRICT_SYSV_CURSES | ||
| static PyObject * | ||
| PyCurses_Use_Default_Colors(PyObject *self) | ||
| @@ -2650,21 +2553,16 @@ | ||
| {"echo", (PyCFunction)PyCurses_echo, METH_VARARGS}, | ||
| {"endwin", (PyCFunction)PyCurses_endwin, METH_NOARGS}, | ||
| {"erasechar", (PyCFunction)PyCurses_EraseChar, METH_NOARGS}, | ||
| - {"filter", (PyCFunction)PyCurses_filter, METH_NOARGS}, | ||
| {"flash", (PyCFunction)PyCurses_flash, METH_NOARGS}, | ||
| {"flushinp", (PyCFunction)PyCurses_flushinp, METH_NOARGS}, | ||
| #ifdef NCURSES_MOUSE_VERSION | ||
| {"getmouse", (PyCFunction)PyCurses_GetMouse, METH_NOARGS}, | ||
| {"ungetmouse", (PyCFunction)PyCurses_UngetMouse, METH_VARARGS}, | ||
| #endif | ||
| - {"getsyx", (PyCFunction)PyCurses_getsyx, METH_NOARGS}, | ||
| {"getwin", (PyCFunction)PyCurses_GetWin, METH_O}, | ||
| {"has_colors", (PyCFunction)PyCurses_has_colors, METH_NOARGS}, | ||
| {"has_ic", (PyCFunction)PyCurses_has_ic, METH_NOARGS}, | ||
| {"has_il", (PyCFunction)PyCurses_has_il, METH_NOARGS}, | ||
| -#ifndef STRICT_SYSV_CURSES | ||
| - {"has_key", (PyCFunction)PyCurses_has_key, METH_VARARGS}, | ||
| -#endif | ||
| {"halfdelay", (PyCFunction)PyCurses_HalfDelay, METH_VARARGS}, | ||
| {"init_color", (PyCFunction)PyCurses_Init_Color, METH_VARARGS}, | ||
| {"init_pair", (PyCFunction)PyCurses_Init_Pair, METH_VARARGS}, | ||
| @@ -2708,7 +2606,6 @@ | ||
| {"resize_term", (PyCFunction)PyCurses_Resize_Term, METH_VARARGS}, | ||
| #endif | ||
| {"savetty", (PyCFunction)PyCurses_savetty, METH_NOARGS}, | ||
| - {"setsyx", (PyCFunction)PyCurses_setsyx, METH_VARARGS}, | ||
| {"setupterm", (PyCFunction)PyCurses_setupterm, | ||
| METH_VARARGS|METH_KEYWORDS}, | ||
| {"start_color", (PyCFunction)PyCurses_Start_Color, METH_NOARGS}, | ||
| @@ -2718,10 +2615,8 @@ | ||
| {"tigetnum", (PyCFunction)PyCurses_tigetnum, METH_VARARGS}, | ||
| {"tigetstr", (PyCFunction)PyCurses_tigetstr, METH_VARARGS}, | ||
| {"tparm", (PyCFunction)PyCurses_tparm, METH_VARARGS}, | ||
| - {"typeahead", (PyCFunction)PyCurses_TypeAhead, METH_VARARGS}, | ||
| {"unctrl", (PyCFunction)PyCurses_UnCtrl, METH_VARARGS}, | ||
| {"ungetch", (PyCFunction)PyCurses_UngetCh, METH_VARARGS}, | ||
| - {"use_env", (PyCFunction)PyCurses_Use_Env, METH_VARARGS}, | ||
| #ifndef STRICT_SYSV_CURSES | ||
| {"use_default_colors", (PyCFunction)PyCurses_Use_Default_Colors, METH_NOARGS}, | ||
| #endif | ||
| diff -Naur a/setup.py b/setup.py | ||
| --- a/setup.py 2016-04-28 13:18:03.397008583 -0700 | ||
| +++ b/setup.py 2016-04-28 13:28:04.595779984 -0700 | ||
| @@ -766,7 +766,7 @@ | ||
| else: | ||
| readline_extra_link_args = () | ||
|
|
||
| - readline_libs = ['readline'] | ||
| + readline_libs = ['readline', 'termcap'] | ||
| if readline_termcap_library: | ||
| pass # Issue 7384: Already linked against curses or tinfo. | ||
| elif curses_library: | ||
| @@ -1359,7 +1359,7 @@ | ||
| # Bug 1464056: If _curses.so links with ncursesw, | ||
| # _curses_panel.so must link with panelw. | ||
| panel_library = 'panelw' | ||
| - curses_libs = [curses_library] | ||
| + curses_libs = [curses_library, 'termcap'] | ||
| curses_incs = find_file('curses.h', inc_dirs, | ||
| [os.path.join(d, 'ncursesw') for d in inc_dirs]) | ||
| exts.append( Extension('_curses', ['_cursesmodule.c'], | ||
| @@ -1373,7 +1373,7 @@ | ||
| elif (self.compiler.find_library_file(lib_dirs, 'termcap')): | ||
| curses_libs = ['curses', 'termcap'] | ||
| else: | ||
| - curses_libs = ['curses'] | ||
| + curses_libs = ['curses', 'termcap'] | ||
|
|
||
| exts.append( Extension('_curses', ['_cursesmodule.c'], | ||
| libraries = curses_libs) ) |
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what i'm looking for tonight, my build system isn't so updated and i tried two successful full builds, but looking at your logs i noticed you are using gcc 6.1.1, so i updated my arch to closely simulate your environment. This way i obtain an error building gcc:host, but it seems a known issue building previous gcc versions with the 6xx series, for now i revert to 5.3 too
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's an easy fix, just build with -std=gnu++98 like this: escalade@bf15cef
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, scratch my previous comment it definitely does not work in my clean/minimal Arch container. I've done about a dozen clean builds with and without gcc6 now. It works on my other Arch build host, but most likely because there is some library/header installed there that makes it work.
Here's what's actually failing:
/root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/toolchain/bin/host-gcc -pthread -fPIC -fno-strict-aliasing -O2 -Wall -pipe -I/root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/toolchain/include -Wno-format-security -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/include -I/root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/toolchain/include -I/root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/Python-2.7.11/Include -I/root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/Python-2.7.11/.x86_64-unknown-linux-gnu -c /root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/Python-2.7.11/Modules/_cursesmodule.c -o build/temp.linux-x86_64-2.7/root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/Python-2.7.11/Modules/_cursesmodule.o /root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/Python-2.7.11/Modules/_cursesmodule.c: In function 'PyCursesWindow_EchoChar': /root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/Python-2.7.11/Modules/_cursesmodule.c:808:18: error: dereferencing pointer to incomplete type 'WINDOW {aka struct __window}' if (self->win->_flags & _ISPAD)@lrusak
If you look at the end of config/optimize you will see why it's linking against /lib64 and /usr/lib64:
# default multiarch support case "uname -m`" ini*86)
if [ -d /lib32 ]; then
HOST_LIBDIR="$HOST_LIBDIR /lib32"
fi
if [ -d /usr/lib32 ]; then
HOST_LIBDIR="$HOST_LIBDIR /usr/lib32"
fi
;;
x86_64)
if [ -d /lib64 ]; then
HOST_LIBDIR="$HOST_LIBDIR /lib64"
fi
if [ -d /usr/lib64 ]; then
HOST_LIBDIR="$HOST_LIBDIR /usr/lib64"
fi
;;
esac
default dirs
`
Even with the system paths removed, it still fails the same way though. Oh and I just now noticed that your user handle spells with an L and not an I :)
@TheUlpio
netbsd-curses:host needs to be compiled with -fPIC btw, Python complains about it when trying to link against libtermcap.a. Not the source of the error but should be noted. Python already gets -fPIC from somewhere else so no need to add that to CFLAGS.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found the solution here: https://bugs.python.org/issue25720
I can't explain why I'm only getting this issue in my Arch container and not my other Arch installation, but the patch fixes it.
Had to refresh the patch: escalade@8eda0cd
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TheUlpio For me your latest patch also fails on a clean build
BUILD netbsd-curses (host)
make[1]: Entering directory '/mnt/share/Projects/LibreELEC.tv/build.LibreELEC-WeTek_Core.arm-8.0-devel/netbsd-curses-47b256a'
ln -sf tic tic/host_tic
Generating compiled terminfo descriptions
TERMINFODIR=./terminfo TOOL_AWK=awk TOOL_NBPERF=nbperf/nbperf TOOL_SED=sed TOOL_SORT=sort TOOL_TIC=tic/host_tic /bin/sh libterminfo/genterms libterminfo/term.h terminfo/terminfo tic/host_tic > libterminfo/compiled_terms.c
libterminfo/genterms: line 52: tic/host_tic: cannot execute binary file: Exec format error
GNUmakefile:480: recipe for target 'libterminfo/compiled_terms.c' failed
make[1]: *** [libterminfo/compiled_terms.c] Error 126
make[1]: Leaving directory '/mnt/share/Projects/LibreELEC.tv/build.LibreELEC-WeTek_Core.arm-8.0-devel/netbsd-curses-47b256a'
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JStyle21
Looks like netbsd-curses is expecting to run one of the produced binaries during compilation, which won't work for you because you are cross compiling for arm cpu. The package needs to be adapted, most likely by compiling host_tic for the host cpu.
EDIT: Try adding HOSTCC="$HOST_CC" CC="$HOST_CC" to make_host in packages/devel/netbsd-curses/package.mk.
@TheUlpio
Upon further testing -fPIC is needed for Python anyways, so disregard my previous comment about that :)
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This confirms that the toolchain is not full independent from the guest system. I explain what i found in my tests:
Finally, i think that for some reason the build process - and only for the Phyton/curses couple - mixes tools from guest and toolchain, this is a critical part also in LFS project. We need to analyze the environment variables passed by build scripts, i also analyzed the ones in the gcc package and this evening i'll start with the Python one. for now my suspect is not about a script error (at least not for the gcc package, there are api breaks there, and up to this commit cross build has always worked), but an hardcoded path somewhere (netbsd-curses? Python curses module?) in package code which forces /usr/lib at linking time.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TheUlpio
I can build the full system as well on my non containerized Arch installation (fully upgraded except gcc6). The problem with _ISPAD is persistent in my minimal container (gcc 5.3 not downgraded), but is solved with the patch mentioned.
As for why /usr/lib is added to the linker path, look at the bottom of config/optimize and you'll see why. The Python build utilizes the HOST_LIBDIR and HOST_INCDIR variables, but they are added last so the toolchain will be used first. But yeah, this leads to the guest libraries/headers being used if they do not exist in the toolchain. Not sure what the intention is but perhaps it's considered OK for host builds to do that as it will be the same arch.
I get the LTO issue with gcc6 as well, going to look more into that. There is definitely something fishy going on, and yeah there were no problems before PR301. Maybe it should be reverted until someone figures it out.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TheUlpio
netbsd-curses needs CC=$HOST_CC in make_host and that takes care of the LTO mismatch, as Python is also compiled with the host compiler. It now successfully builds in my Arch container with gcc6.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@escalade that has actually made it worse... :)
http://pastebin.com/5UkHBGGT
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I thought it was the host build but it's the target build that fails for you. You will need HOSTCC="$HOST_CC" CC="$TARGET_CC" in make_target.
I got the same error as you actually, but changing that fixed it.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@escalade
It made the target build work but after a few packages also started building the host ncurses and failed on the same error i got earlier, is it supposed to build 2 different ncurses ?
http://pastebin.com/wNDrq23G
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, one for host and one for target. Probably the build system notices a new timestamp on the package.mk and rebuilds. This seems to work for me: https://github.com/escalade/LibreELEC.tv/blob/a54a6491bdae7d6151d4a973d0b1ee08bfbd5388/packages/devel/netbsd-curses/package.mk
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still fails on the same error with the host curses :( and my cross compiling skills are weak to know why it's wrong.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cleaned out the build directory and both netbsd-curses:host and netbsd-curses:target builds and installs here with the above package.mk. "Exec format error" means the binary it's trying to run has been compiled for a different cpu than what you have. So in your case it was probably compiled for ARM.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is correct i am building the amlogic package so it's for ARM but i still need it :D
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When some small binary needs to be build for host and to be run when building target sometimes require copying to correct location. Like this for mysql.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't be necessary in this case as the makefile is set up to handle cross compiling. It'll use HOSTCC to build the tool
@JStyle21
If the target build had already finished and it tried to build the host build again, then I'm guessing the issue is that the target binaries are still there and causing the issue. Do a "scripts/clean netbsd-curses" and try again. I think perhaps a "make clean" as a last step in the makeinstall sections might be in order, as we don't build in a subdir. I just finished another successful rpi (arm) build so it really should be working for you as well.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@escalade
Still fails after "scripts/clean netbsd-curses" will try "make clean" tomorrow but just to be sure can you confirm the changes made from the vanilla version, it should be only the patch from @TheUlpio and your version of the package.mk right?
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's my latest version:
https://github.com/escalade/LibreELEC.tv/blob/f727ed0d2387825170a6355ac5119deac60549c4/packages/devel/netbsd-curses/package.mk
Built fine both for generic and rpi.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the new version i got a different error but the result is as before target builds fine and host fails.
http://pastebin.com/tJcF2TJU
Will try a clean update build later on as mentioned in my previous reply.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What OS is this? Some older Debian version perhaps?
You could try this: https://developer.pidgin.im/ticket/9439
Probably not a proper fix, but might get you around the issue.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm using Gentoo Amd64 but since it fails on the host ncurses it's clear where the problem is.
I will take it up with Gentoo support to discover more and update once i have progressed, i don't really want to make that quick hack because it's not a real solution to the issue but thanks for pointing that out.
Oh and i've tried it on a clean build it's the same.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, i'm back here:)
@JStyle21 can you please test this patch:
package.mk.patch.txt
It disables building of the curses module in the Python:host part and leave it untouched in the target part. It works well for me and involves only package.mk.
Sincerely i never understood the need to build the Python curses module, but this is the development line, so ok for the target system, but in the host part it is useless imho.
Apply only this on a fresh LE tree, without any other Python/curses related patch in this thread.
@escalade using your patchset (not the last one indeed, i have to try, so don't take it as an absolute!) i can successfully build the full system, but some curses programs (eg mc, known to be quite problematic due to direct access to curses abi) won't build. They complains at compile time that cannot find ltermcap in the sysroot directory (indeed, it's there!). I'm still investigating, but i subspect that it cannot be linked due to the fPIC flag in netbsd-curses: in my knowledge (maybe i'm wrong) PIC is intended for shared libraries and with this flag gcc uses the same ldflags, -l and -L for both static and shared objects.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TheUlpio
I think you miss something in your patch, you set EXCLUDE_DIRS but don't actually do anything with the variable. Guess you want to rm them :)
Also, could you comment on #390 please? I made a PR to try and fix this. I think you are right about -fPIC and probably we don't need curses at all in host like you say. In that case we don't need to install netbsd-curses:host either right?
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Certainly won't build if netbsd-curses:host is compiled without -fPIC:
/root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/toolchain/bin/host-gcc -pthread -shared -Wl,-rpath,/root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/toolchain/lib -L/root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/toolchain/lib -Wl,-rpath,/root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/toolchain/lib -L/root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/toolchain/lib -fno-strict-aliasing -O2 -Wall -pipe -I/root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/toolchain/include -Wno-format-security -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I/root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/Python-2.7.11/Include build/temp.linux-x86_64-2.7/root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/Python-2.7.11/Modules/_cursesmodule.o -L/usr/lib -L/lib -L/usr/lib64 -L/lib64 -L/root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/toolchain/lib -L. -lncursesw -ltermcap -lpython2.7 -o build/lib.linux-x86_64-2.7/_curses.so /usr/sbin/ld: /root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/toolchain/lib/libncursesw.a(acs.o): relocation R_X86_64_32 against_acs_char' can not be used when making a shared object; recompile with -fPIC/root/LibreELEC.tv/build.LibreELEC-Generic.x86_64-8.0-devel/toolchain/lib/libncursesw.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
`
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On second thought, I only used -fPIC for netbsd-curses:host, shouldn't you be linking against target libs?
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TheUlpio With this patch both ncurses and python have been built successfully, will try a clean build tomorrow as well but i don't see why it should fail.
Thanks 👍
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ops, this is what happens making a thousands changes on the same code...
I agree with this, but the error is at configure time and config.log doesn't give great information: library path is correctly set to $SYSROOT but cannot find the (existing) library. Building without fPIC gives no errors (as i wrote before, i'm still investigating, now i have two trees, one with my patch and one with your patchset - the one you committed as PR so i'm sure is the last one). My HTPC is in the build process...
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uh, 390 was updated... I need to update my build tree too and restart building.
Ok, from now all related to your patchset will be commented in that thread:)
@JStyle21 Thanks to try this, i'll wait to know your results for a fresh build...
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can just clean Python/netbsd-curses and remove build_/image/.stamps/(netbsd-curses|Python)/install_, no need to rebuild.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, not in my case, the same have to be done for a lot of packages and dependencies... I don't build mc, powetop and others (curses and Python related) as addons, they are in tree because Estuary exposes all addons in the addon tab, and i don't like to see programs that cannot run in the gui
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do the same thing as I dislike addons as well. In any case, cleaning the packages and their dependencies should be faster than rebuilding the entire toolchain :)
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@escalade Thanks for the suggestion but by the time you wrote that i already cleaned the packages.
@TheUlpio On a new clean build it passed about 90% and crashed at Kodi but i'm not sure it's related to this, could also be one of the latest commits.
Here is the log http://pastebin.com/qZPPqM54
Update:
Now it looks even stranger
BUILD kodi (target)
make: getcwd: No such file or directory
make[1]: Entering directory ''
make[1]: *** No rule to make target 'configure.ac', needed by 'configure'. Stop.
make[1]: Leaving directory ''
Makefile:18: recipe for target 'amlpkg' failed
make: *** [amlpkg] Error 2
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My tree has only been tested on Generic/RPi. I've updated Kodi in my tree to the latest git, you might want to revert that commit to get the default version from LE.
The "getcwd" error is because you didn't clean Kodi before trying again.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JStyle21 I use the master LE git tree, so kodi is a bit outdated. I agree with escalade, you have to clean kodi
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok so the getcwd was because i didn't clean kodi after the 1st attempt but that was because from past experience i assumed that if it failed to build it will auto clean itself on the next run which was the case in past attempts, cleaned manually and got the original error.
@escalade
What does that mean? i'm using the master LE branch with the patch from @TheUlpio that is it. Are you saying i should pull the latest kodi 17 branch\commits to my LE tree?
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I misread your comment so ignore that. Did you try #390?
EDIT: I think @TheUlpio's suggestion of disabling readline/curses module for the host is the better option at this point.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@escalade
#390 has the same issue with MB_LEN_MAX being wrong
@TheUlpio
Isn't enabling the modules was the whole point of this commit?
I still didn't understand what am i supposed to do with the KODI error i had.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JStyle21
The Python package is built two times. One time for the "host" toolchain, which is only to be used when building other packages. The other is for the "target", which is the system you are cross compiling for. @TheUlpio's suggestion is only disable for the host build, not for the target. I've tested that and it works fine, Python in LibreELEC still has readline capability.
I've changed #390 to do this as well.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@escalade
Thanks for clarifying that out 👍
Only 2 things i'm wondering here:
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ubuntu doesn't have any problem building the current tree - I've clean built RPi/RPi2/Generic several times each since
#390#301 merged.53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#390 isn't merged yet :)
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, #301. :)
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, there certainly are issues with other distributions as you can see from the comments. There really is no use for the readline/curses modules for the host build anyways. There's no issue compiling for target.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are certainly issues with some other distributions, but Ubuntu (16.04 in my case) doesn't appear to be one of them - no idea why that should be, but my original comment is only answering the question posed by @JStyle21, not contradicting anything already posted.
If readline/curses isn't required by host and fixes the build issue then it seems like an acceptable solution to me...
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MilhouseVH
Ah, yeah I missed that comment sorry.
@JStyle21
I reworked #390 did you try the latest? Now there's only a minor change which disables building the modules.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MilhouseVH
Thanks for the answer tho i'm still wondering to this day why ubuntu is so often used for a build OS while other distro's are not, it's like it's more stable because it is popular and it is popular because it is stable so it's actually a paradox to me.
@escalade @TheUlpio
I tried the new #390 but it fails on the same kodi problem as mentioned before, i'm still clueless to why it is failing there as no error is given prior to failing, only warnings...
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JStyle21 the last #390 involves only host part. As far as i know kodi depends on the target build of the Python package, so no changes. Now i'm a bit confused. Can you confirm that with #301 reverted you don't hit issues?
Maybe useful to involve kodi people to know a possible way to improve build logs.
As last try, are you able to send me (stripped of sensible data, of course) a dd image of your gentoo so i can reproduce locally your build system)?
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or i can use the new live dvd?
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TheUlpio As far as i remember once i originally reverted #301 i made a successful build (which i still have), it is noted at the beginning of the comments but i will try a fresh master and revert #301 now.
Regarding the image it's a bit problematic in my set up i'm using multiple HD's and an SSD so many things are linked for example the user profile.
I'm not familiar with the "new live dvd", could you elaborate on it?
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes of course, it's a news from phoronix, a new gentoo live dvd is out today, i'll try with it :)
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok got it, please update once you have tried i'm also interested :)
As far as i could see #301 also broke on kodi but i swear i didn't do any substantial changes since this commit has passed about 14 days ago or so...
it could be something i changed in my system or can it be my understanding of git, if i do a git revert with this commit will it undo all changed since then or just the last commit?
i think it's time to do some testing on a few distros to see how is this responding there...
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW this is what i got from the gentoo forums:
Any idea how to test the suggested flags or what to reply on the second part?
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"host-gcc" is just a shell script that runs ccache /usr/bin/gcc. Doesn't look like the error is related to this. Did you try a full rebuild?
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was regarding the MB_LEN error, but in general as i mentioned the current error is with the Kodi package both on #390 and #301 and there are no clear errors so i don't know why is it happening...
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like a broken record here, did you do a full rebuild with #301 reversed and get the same error?
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I cloned master then ran git revert da14fbc and did a full build to get the error.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So your issue is unrelated to this commit then.
53eca15There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@escalade @TheUlpio @MilhouseVH @lrusak
Just wanted to update and thank you all for your support throughout this commit, #390 just passed for me so it defiantly works without any issues.
I've learned a lot from this experinace and as my knowledge grows i will try to contribute back as well :)
Any case anyone wonders about the kodi issue or stumbles upon this: