Skip to content
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

What is the correct way to build kterm with static libvte? #7

Closed
N46AN opened this issue Nov 13, 2016 · 11 comments
Closed

What is the correct way to build kterm with static libvte? #7

N46AN opened this issue Nov 13, 2016 · 11 comments

Comments

@N46AN
Copy link

N46AN commented Nov 13, 2016

Hello, glad to see this fantastic project still in active development. Kterm has helped me immensely during my past ownership of a kindle device. I'm not sure if this is the right place to ask for help, especially when it involves asking newbie questions in a bug tracker.

I've skimmed through the file configure.ac and It seems that building for Kindle with static libvte involves correctly exporting VTE_LIBS. I've tried setting VTE_LIBS to 'libs/libvte.a' '-l:libs/libvte.a' '-llibs/libvte.a' to no avail. (source of static libvte.a : #2)

My building environment is an emulated armel debian jessie in qemu.

Thanks!

@bfabiszewski
Copy link
Owner

What happens if you use following configure options?
./configure --enable-kindle --sysconfdir=/mnt/us/extensions/kterm

It should automatically pick up static libvte (through pkg-config). Of course you should first install vte dev package which includes the static library. It should be available for your debian distro.

@N46AN
Copy link
Author

N46AN commented Nov 14, 2016

Thanks for your timely reply. Sorry I did not provide detailed infomation in the first post. I already had libvte-dev installed which provides /usr/lib/libvte.a. Also my previous run of ./configure had already included those options.
Note that I'm compiling natively in an emulated armel environment. Is this the possible culprit?
Here are some more related infomation: https://paste.debian.net/plain/895401

@bfabiszewski
Copy link
Owner

Thanks for detailed info!

I should have mentioned it in the README that for the static building with libvte you also need to provide libtermcap.so. Could you please install libtinfo-dev (it contains libtermcap) package and try again?

If it still doesn't work please post config.log file.

@N46AN
Copy link
Author

N46AN commented Nov 15, 2016

Sorry for the late reply due to timezone differences. I found out that I already had libtinfo-dev installed (again...)

n46an@jessie-kindledev:~/src/kterm/kterm2.3$ dpkg -l | grep libtinfo-dev
ii  libtinfo-dev:armel                 5.9+20140913-1+b1           armel        developer's library for the low-level terminfo library
n46an@jessie-kindledev:~/src/kterm/kterm2.3$ find /usr/lib | grep libtermcap.so
/usr/lib/arm-linux-gnueabi/libtermcap.so

...and config.log is indeed the right direction since even as a novice I can see some possible problems with my building environment, which I've been unable to debug further due to my knowledge limitations.
Here is the complete content of config.log: https://paste.debian.net/plain/895733
Thanks!

n46an@jessie-kindledev:~$ find /lib | grep libm.so
/lib/arm-linux-gnueabi/libm.so.6
n46an@jessie-kindledev:~$ apt-cache policy libc6
libc6:
  Installed: 2.19-18+deb8u6
  Candidate: 2.19-18+deb8u6
  Version table:
 *** 2.19-18+deb8u6 0
        500 https://mirrors.ustc.edu.cn/debian/ jessie/main armel Packages
        100 /var/lib/dpkg/status
     2.19-18+deb8u3 0
        500 http://security.debian.org/ jessie/updates/main armel Packages

@bfabiszewski
Copy link
Owner

bfabiszewski commented Nov 15, 2016

Thanks! Now it complains about -lm. The order of libs on the command line is probably different on your platform. We could just add it to TERMCAP_LIBS, but let's try more universal approach first and get all needed libs for static linking from pkg-config. Plus we check for termcap and also add it, because at least on my platform it is not mentioned in the pkg-config --static output (a bug?).

Could you please try to apply following patch to configure.ac. Rerun ./autogen.sh and try to configure again.

diff --git a/configure.ac b/configure.ac
index fdd8042..1f6a6eb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -33,12 +33,26 @@ AM_COND_IF([KINDLE],
      AC_MSG_WARN([building for Kindle without ARM toolchain])])

   dnl Libtermcap is needed for static builds with vte < 2.91
-  TERMCAP_LIBS=-ltermcap
+  require_termcap=yes
   AC_DEFINE([KINDLE], [1])

+  saved_PKG_CONFIG=$PKG_CONFIG
+  PKG_CONFIG="$PKG_CONFIG --static"
   AM_COND_IF([GTK3],
-    [PKG_CHECK_MODULES([VTE], [vte-2.91], [TERMCAP_LIBS=], [PKG_CHECK_MODULES([VTE], [vte-2.90])])],
+    [PKG_CHECK_MODULES([VTE], [vte-2.91], [require_termcap=no], [PKG_CHECK_MODULES([VTE], [vte-2.90])])],
     [PKG_CHECK_MODULES([VTE], [vte])])
+  PKG_CONFIG=$saved_PKG_CONFIG
+
+  AM_CONDITIONAL([TERMCAP_NEEDED], [test "x$require_termcap" = "xyes"])
+  TERMCAP_LIBS=
+  AM_COND_IF([TERMCAP_NEEDED],
+    [saved_LIBS=$LIBS
+     LIBS=
+     AC_SEARCH_LIBS([tgetent],[termcap termlib curses ncurses],
+       [TERMCAP_LIBS=$LIBS],
+       [AC_MSG_WARN([libtermcap is needed for static build])])
+     LIBS=$saved_LIBS
+    ],[])

   AC_MSG_CHECKING([whether libvte may be linked statically])
   dnl This will only work with gnu linker

@N46AN
Copy link
Author

N46AN commented Nov 15, 2016

Hi,
This is indeed the right direction. I followed the procedure: https://paste.debian.net/plain/895853
...and obtained the config.log: https://paste.debian.net/plain/895854
Since it complains about missing -lselinux and -lffi, I installed libffi-dev libselinux1-dev and tried again. This time it worked! https://paste.debian.net/plain/895874 https://paste.debian.net/plain/895873
Then I proceeded to build the binary, transferred to kpw3 5.6.5 and did a test run, only to be greeted with a lot of missing shared libs: https://paste.debian.net/plain/895884
(At first I tried manually supply the missing libs to LD_LIBRARY_PATH, but then it became clear that there were too many of them, and I just did a ldd kterm instead ;-) )
It seems that a lot more dependencies have been introduced?
Thanks!

@bfabiszewski
Copy link
Owner

Your problem is that you are building for a system with different library versions and dependencies. Depending on how big the differences are you may never be able to succeed.

Let's check what happens if you provide just the minimal set of dependencies. Try following patch that only adds libm and libtermcap as shared dependencies. You must first restore the initial version of configure.ac.

diff --git a/configure.ac b/configure.ac
index fdd8042..271996d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -33,16 +33,27 @@ AM_COND_IF([KINDLE],
      AC_MSG_WARN([building for Kindle without ARM toolchain])])

   dnl Libtermcap is needed for static builds with vte < 2.91
-  TERMCAP_LIBS=-ltermcap
+  require_termcap=yes
   AC_DEFINE([KINDLE], [1])

   AM_COND_IF([GTK3],
-    [PKG_CHECK_MODULES([VTE], [vte-2.91], [TERMCAP_LIBS=], [PKG_CHECK_MODULES([VTE], [vte-2.90])])],
+    [PKG_CHECK_MODULES([VTE], [vte-2.91], [require_termcap=no], [PKG_CHECK_MODULES([VTE], [vte-2.90])])],
     [PKG_CHECK_MODULES([VTE], [vte])])

+  AM_CONDITIONAL([TERMCAP_NEEDED], [test "x$require_termcap" = "xyes"])
+  TERMCAP_LIBS=
+  AM_COND_IF([TERMCAP_NEEDED],
+    [saved_LIBS=$LIBS
+     LIBS=
+     AC_SEARCH_LIBS([tgetent],[termcap termlib curses ncurses],
+       [TERMCAP_LIBS=$LIBS],
+       [AC_MSG_WARN([libtermcap is needed for static build])])
+     LIBS=$saved_LIBS
+    ],[])
+
   AC_MSG_CHECKING([whether libvte may be linked statically])
   dnl This will only work with gnu linker
-  [VTE_STATIC_LIBS=`echo "$VTE_LIBS" | sed -e "s/\(-lvte[-_.0-9]*\)/-Wl,-Bstatic \1 -Wl,-Bdynamic $TERMCAP_LIBS/g"`]
+  [VTE_STATIC_LIBS=`echo "$VTE_LIBS" | sed -e "s/\(-lvte[-_.0-9]*\)/-Wl,-Bstatic \1 -Wl,-Bdynamic $TERMCAP_LIBS -lm/g"`]
   saved_CFLAGS=$CFLAGS
   saved_LIBS=$LIBS
   CFLAGS="$GTK_CFLAGS $VTE_CFLAGS"

@N46AN
Copy link
Author

N46AN commented Nov 17, 2016

Hello, sorry for the late reply. I tested the above procedure. This time, after supplying one single libtinfo.so.5, all dependencies seemed to have been satisfied as reported by ldd. Then it complained about:

/mnt/us/extensions/kterm/bin/kterm: symbol lookup error: 
/mnt/us/extensions/kterm/bin/kterm: undefined symbol: g_mutex_lock

I guess this is due to libglib version mismatch(?) I tried building without libvte statically linked,(i.e. use the original configure.ac) and manually supplying libvte.so.9, libglib-2.0.so.0, libpcre.so.3, libtinfo.so.5 and the binary was then able to startup.

So after all these attempts, I am convinced that the real reason behind all these hassle is because I did not set up the building environment properly. So I wonder what is the preferred way to set up a toolchain for kindle devices? Thanks!

@bfabiszewski
Copy link
Owner

Thanks for testing. Could you please test one more configuration. I am looking for a way to use only really needed libraries out of all given by pkg-config --static. The Kindle build using autotools with static libvte will always be a hack though.

diff --git a/configure.ac b/configure.ac
index fdd8042..04ccd87 100644
--- a/configure.ac
+++ b/configure.ac
@@ -33,16 +33,30 @@ AM_COND_IF([KINDLE],
      AC_MSG_WARN([building for Kindle without ARM toolchain])])

   dnl Libtermcap is needed for static builds with vte < 2.91
-  TERMCAP_LIBS=-ltermcap
+  require_termcap=yes
   AC_DEFINE([KINDLE], [1])

+  saved_PKG_CONFIG=$PKG_CONFIG
+  PKG_CONFIG="$PKG_CONFIG --static"
   AM_COND_IF([GTK3],
-    [PKG_CHECK_MODULES([VTE], [vte-2.91], [TERMCAP_LIBS=], [PKG_CHECK_MODULES([VTE], [vte-2.90])])],
+    [PKG_CHECK_MODULES([VTE], [vte-2.91], [require_termcap=no], [PKG_CHECK_MODULES([VTE], [vte-2.90])])],
     [PKG_CHECK_MODULES([VTE], [vte])])
+  PKG_CONFIG=$saved_PKG_CONFIG
+
+  AM_CONDITIONAL([TERMCAP_NEEDED], [test "x$require_termcap" = "xyes"])
+  TERMCAP_LIBS=
+  AM_COND_IF([TERMCAP_NEEDED],
+    [saved_LIBS=$LIBS
+     LIBS=
+     AC_SEARCH_LIBS([tgetent],[curses ncurses readline termcap],
+       [TERMCAP_LIBS=$LIBS],
+       [AC_MSG_WARN([libtermcap is needed for static build])])
+     LIBS=$saved_LIBS
+    ],[])

   AC_MSG_CHECKING([whether libvte may be linked statically])
   dnl This will only work with gnu linker
-  [VTE_STATIC_LIBS=`echo "$VTE_LIBS" | sed -e "s/\(-lvte[-_.0-9]*\)/-Wl,-Bstatic \1 -Wl,-Bdynamic $TERMCAP_LIBS/g"`]
+  [VTE_STATIC_LIBS=`echo "-Wl,--as-needed $VTE_LIBS -Wl,--no-as-needed" | sed -e "s/\(-lvte[-_.0-9]*\)/-Wl,-Bstatic \1 -Wl,-Bdynamic $TERMCAP_LIBS/g"`]
   saved_CFLAGS=$CFLAGS
   saved_LIBS=$LIBS
   CFLAGS="$GTK_CFLAGS $VTE_CFLAGS"

Regarding you question about building environment I don't have a simple answer. There are many different ways. I built my environment for Kindle years ago with scratchbox2, but this tool is not developed any more.

If you manage to gather Kindle version libraries and headers into a separate tree on your machine you may be able to force your compiler to use it as its sysroot (eg. by creating gcc wrapper).

@N46AN
Copy link
Author

N46AN commented Nov 20, 2016

Thanks for explaining about the building environment. I 'sort of' understand that building for kindle is a special case that cannot be covered by a generic method.
I tested the above procedure, here is the produced config.log: https://paste.debian.net/plain/896827
Makefile: https://paste.debian.net/plain/896833
Executing it on the kindle yielded the same result as the last attempt, which is a missing libtinfo.so.5 and 'undefined symbol: g_mutex_lock'
ldd kterm: https://paste.debian.net/896907/
Should there be any more tests It would be my pleasure to help.
Thanks!

@bfabiszewski
Copy link
Owner

Thanks for testing!
The last patch seems to solve the problem with missing linker flags and it doesn't add unneeded dependencies.

Regarding your problem. Glib version on my Kindle is 2.29.18. On debian jessie it is 2.42.1. Either setup dedicated sysroot with Kindle libraries and development headers (at point it to your compiler) or maybe try with older version of debian (squeeze?).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants