Hi August, On Fri, May 10, 2013 at 11:33:13AM +0200, August Karlstrom wrote:
I'm trying to compile Dillo 3.0.3 but I get an error from the linker saying:
/usr/bin/ld: xembed.o: undefined reference to symbol 'XSync' /usr/bin/ld: note: 'XSync' is defined in DSO /usr/lib/x86_64-linux-gnu/libX11.so.6 so try adding it to the linker command line
How do I add -lX11 to the linker command line? I have tried
$ LDLIBS=-lX11 make
but it makes no difference. My OS is Lubuntu 13.04.
Could you please post the linker command line? You could try export LDFLAGS=-lX11 and then run configure;make again. Please let us know how this works. It might be that we are missing an explicit -lX11 somewhere and rely on fltkconfig --ldflags to add it - which may not be sufficient in some cases. Cheers, Johannes
On 2013-05-10 11:48, Johannes Hofmann wrote:
Could you please post the linker command line?
Sure, here it is: g++ -I/usr/include/libpng12 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/freetype2 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dillo dillo.o paths.o tipwin.o ui.o uicmd.o bw.o cookies.o auth.o md5.o digest.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o domain.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -L/usr/lib/x86_64-linux-gnu -lpng12 -lpng12 -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk -lz -lpthread
You could try export LDFLAGS=-lX11 and then run configure;make again.
Unfortunately, this did not make a difference. Thanks Johannes for taking the time. Regards, August
On Fri, May 10, August Karlstrom wrote:
On 2013-05-10 11:48, Johannes Hofmann wrote:
Could you please post the linker command line?
Sure, here it is:
g++ -I/usr/include/libpng12 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/freetype2 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dillo dillo.o paths.o tipwin.o ui.o uicmd.o bw.o cookies.o auth.o md5.o digest.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o domain.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -L/usr/lib/x86_64-linux-gnu -lpng12 -lpng12 -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk -lz -lpthread
It is identical to mine (Debian wheezy amd64) except this option:
-Wl,-Bsymbolic-functions
Maybe you should try it without it (simply by typing the command manually). The documentation does not give a reason for hope, however (man ld): -Bsymbolic-functions When creating a shared library, bind references to global function symbols to the definition within the shared library, if any. This option is only meaningful on ELF platforms which support shared libraries.
You could try export LDFLAGS=-lX11 and then run configure;make again.
I have found it always convenient to type something like: $ CFLAGS=... ./configure The modified variables become part of the generated Makefile. Sebastian
On 2013-05-10 17:44, Sebastian Geerken wrote:
It is identical to mine (Debian wheezy amd64) except this option:
-Wl,-Bsymbolic-functions
Maybe you should try it without it (simply by typing the command manually). The documentation does not give a reason for hope, however (man ld):
-Bsymbolic-functions When creating a shared library, bind references to global function symbols to the definition within the shared library, if any. This option is only meaningful on ELF platforms which support shared libraries.
Unfortunately I get the same error after removing -Wl,-Bsymbolic-functions. /August
On 2013-05-10 22:48, August Karlstrom wrote:
On 2013-05-10 17:44, Sebastian Geerken wrote:
It is identical to mine (Debian wheezy amd64) except this option:
-Wl,-Bsymbolic-functions
Maybe you should try it without it (simply by typing the command manually). The documentation does not give a reason for hope, however (man ld):
-Bsymbolic-functions When creating a shared library, bind references to global function symbols to the definition within the shared library, if any. This option is only meaningful on ELF platforms which support shared libraries.
Unfortunately I get the same error after removing -Wl,-Bsymbolic-functions.
Linking with libX11 is what's missing: LIBS=-lX11 ./configure make make install This means that libX11 needs to be added to the build scripts. Regards, August
On Sat, May 11, 2013 at 06:46:53PM +0200, August Karlstrom wrote:
On 2013-05-10 22:48, August Karlstrom wrote:
On 2013-05-10 17:44, Sebastian Geerken wrote:
It is identical to mine (Debian wheezy amd64) except this option:
-Wl,-Bsymbolic-functions
Maybe you should try it without it (simply by typing the command manually). The documentation does not give a reason for hope, however (man ld):
-Bsymbolic-functions When creating a shared library, bind references to global function symbols to the definition within the shared library, if any. This option is only meaningful on ELF platforms which support shared libraries.
Unfortunately I get the same error after removing -Wl,-Bsymbolic-functions.
Linking with libX11 is what's missing:
LIBS=-lX11 ./configure make make install
This means that libX11 needs to be added to the build scripts.
I'm using Debian on amd64 and -lX11 doesn't appear in the options, though it compiles OK, but libX11.so.6 gets linked anyway! (AFAICS X11 gets in indirectly by including FL/x.H in xembed.c). What OS are you using? -- Cheers Jorge.-
On 2013-05-11 21:38, Jorge Arellano Cid wrote:
On Sat, May 11, 2013 at 06:46:53PM +0200, August Karlstrom wrote:
Linking with libX11 is what's missing:
LIBS=-lX11 ./configure make make install
This means that libX11 needs to be added to the build scripts.
I'm using Debian on amd64 and -lX11 doesn't appear in the options, though it compiles OK, but libX11.so.6 gets linked anyway!
(AFAICS X11 gets in indirectly by including FL/x.H in xembed.c).
What OS are you using?
Lubuntu 13.04 with Blackbox window manager. /August
Hi, On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote:
X11 is needed in src/xembed.cc. It seems that on most systems it is linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others not, so that an additional "-lX11" is necessary.
It's rather "on newer systems" than "on others". And "most systems" is rather "on older systems".
Should we add it generally? It does not harm; we have only to care about other systems than X11.
Definitely. On Sat, May 11, 2013 at 03:38:19PM -0400, Jorge Arellano Cid wrote:
I'm using Debian on amd64 and -lX11 doesn't appear in the options, though it compiles OK, but libX11.so.6 gets linked anyway!
Which release of Debian? Because for Debian Unstable, this is no more the case: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713557 On Sat, May 11, 2013 at 11:44:52PM +0200, August Karlstrom wrote:
What OS are you using?
Lubuntu 13.04 with Blackbox window manager.
It's possible that Ubuntu already uses the same toolchain in 13.04 which in Debian only was available in the Experimental branch until recently[1]. [1] e.g. https://lists.debian.org/debian-sparc/2013/06/msg00016.html Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)
Hi, On Sun, Jun 23, 2013 at 04:20:13PM +0200, Axel Beckert wrote:
On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote:
X11 is needed in src/xembed.cc. It seems that on most systems it is linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others not, so that an additional "-lX11" is necessary.
On non-linux architectures, there's more than -lX11 necessary. I suspect a -lpthread for Hurd and kFreeBSD, maybe also FreeBSD, not sure: https://buildd.debian.org/status/fetch.php?pkg=dillo&arch=hurd-i386&ver=3.0.3-4&stamp=1372034504 https://buildd.debian.org/status/fetch.php?pkg=dillo&arch=kfreebsd-amd64&ver=3.0.3-4&stamp=1372033536 https://buildd.debian.org/status/fetch.php?pkg=dillo&arch=kfreebsd-i386&ver=3.0.3-4&stamp=1372033408 For Hurd, the fix looks obvious, for kfreebsd, I'll have to test first, if that suffices. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)
2013/6/24 Axel Beckert <abe at deuxchevaux.org>
Hi,
On Sun, Jun 23, 2013 at 04:20:13PM +0200, Axel Beckert wrote:
On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote:
X11 is needed in src/xembed.cc. It seems that on most systems it is linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others not, so that an additional "-lX11" is necessary.
On non-linux architectures, there's more than -lX11 necessary. I suspect a -lpthread for Hurd and kFreeBSD, maybe also FreeBSD, not sure:
I got this output from fltk-config --ldflags on FreeBSD 8.2. -L/usr/local/lib -R/usr/local/lib -lfltk -lXext -lXft -lfontconfig -lXinerama -lpthread -lm -lX11 Regards, furaisanjin
Hi, On Mon, Jun 24, 2013 at 09:02:44PM +0900, furaisanjin wrote:
2013/6/24 Axel Beckert <abe at deuxchevaux.org>
On Sun, Jun 23, 2013 at 04:20:13PM +0200, Axel Beckert wrote:
On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote:
X11 is needed in src/xembed.cc. It seems that on most systems it is linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others not, so that an additional "-lX11" is necessary.
On non-linux architectures, there's more than -lX11 necessary. I suspect a -lpthread for Hurd and kFreeBSD, maybe also FreeBSD, not sure:
I got this output from fltk-config --ldflags on FreeBSD 8.2.
-L/usr/local/lib -R/usr/local/lib -lfltk -lXext -lXft -lfontconfig -lXinerama -lpthread -lm -lX11
Ah, ok. Thanks for checking! This looks fine, indeed. On Debian GNU/kFreeBSD I just get "-L/usr/lib/i386-kfreebsd-gnu -lfltk". The missing -lX11 seems to be an issue with the libfltk1.3-dev package in Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713933 I just checked the minimal example from that bug report. It doesn't seem to need pthreads on kfreebsd despite the string "pthreads" appears in libfltk.a and libfltk.so. I suspect the remaining libs (-lXext -lXft -lfontconfig -lXinerama -lpthread -lm) are not strictly necessary for every program either. (Or there's something else different on FreeBSD.) Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)
On Sat, May 11, August Karlstrom wrote:
[...] Linking with libX11 is what's missing:
LIBS=-lX11 ./configure make make install
This means that libX11 needs to be added to the build scripts.
I've looked at the fltk-config script, and found that it has two options: $ fltk-config --ldflags -L/usr/lib/x86_64-linux-gnu -lfltk $ fltk-config --ldstaticflags /usr/lib/x86_64-linux-gnu/libfltk.a -lXext -lXft -lfontconfig -lfontconfig -lXinerama -ldl -lm -lX11 The configure script of dillo uses "--ldflags", which is used for dynamic linking against "libfltk.so", while "--ldstaticflags" is used for linking against "libfltk.a". Which files of the two do you have in the respective directory (/usr/lib/x86_64-linux-gnu/)? My guess is that "libfltk.so" does not exist and so dillo is linked statically. (A simple test confirms this: renaming "libfltk.so" results in similar errors.) For this case, the configure script of dillo should be modified. My suggestions: - Generally make it possible to use "--ldstaticflags". An option for this, "--enable-static-fltk"? - There should be some tests to detect this error. Sebastian
On 2013-05-13 13:21, Sebastian Geerken wrote:
On Sat, May 11, August Karlstrom wrote:
[...] Linking with libX11 is what's missing:
LIBS=-lX11 ./configure make make install
This means that libX11 needs to be added to the build scripts.
I've looked at the fltk-config script, and found that it has two options:
$ fltk-config --ldflags -L/usr/lib/x86_64-linux-gnu -lfltk $ fltk-config --ldstaticflags /usr/lib/x86_64-linux-gnu/libfltk.a -lXext -lXft -lfontconfig -lfontconfig -lXinerama -ldl -lm -lX11
This is what I get: $ fltk-config --ldflags -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk $ fltk-config --ldstaticflags -Wl,-Bsymbolic-functions /usr/lib/x86_64-linux-gnu/libfltk.a -lXext -lXft -lfontconfig -lfontconfig -lXinerama -ldl -lm -lX11
The configure script of dillo uses "--ldflags", which is used for dynamic linking against "libfltk.so", while "--ldstaticflags" is used for linking against "libfltk.a". Which files of the two do you have in the respective directory (/usr/lib/x86_64-linux-gnu/)? My guess is that "libfltk.so" does not exist and so dillo is linked statically.
I do have both the dynamic and the static libraries: $ ls /usr/lib/x86_64-linux-gnu/libfltk* /usr/lib/x86_64-linux-gnu/libfltk.a /usr/lib/x86_64-linux-gnu/libfltk_cairo.a /usr/lib/x86_64-linux-gnu/libfltk_cairo.so /usr/lib/x86_64-linux-gnu/libfltk_cairo.so.1.3 /usr/lib/x86_64-linux-gnu/libfltk_forms.a /usr/lib/x86_64-linux-gnu/libfltk_forms.so /usr/lib/x86_64-linux-gnu/libfltk_forms.so.1.3 /usr/lib/x86_64-linux-gnu/libfltk_gl.a /usr/lib/x86_64-linux-gnu/libfltk_gl.so /usr/lib/x86_64-linux-gnu/libfltk_gl.so.1.3 /usr/lib/x86_64-linux-gnu/libfltk_images.a /usr/lib/x86_64-linux-gnu/libfltk_images.so /usr/lib/x86_64-linux-gnu/libfltk_images.so.1.3 /usr/lib/x86_64-linux-gnu/libfltk.so /usr/lib/x86_64-linux-gnu/libfltk.so.1.3 Regards, August
On Sat, May 11, August Karlstrom wrote:
Linking with libX11 is what's missing:
LIBS=-lX11 ./configure make make install
This means that libX11 needs to be added to the build scripts.
On Mon, May 13, August Karlstrom wrote:
This is what I get:
$ fltk-config --ldflags -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk $ fltk-config --ldstaticflags -Wl,-Bsymbolic-functions /usr/lib/x86_64-linux-gnu/libfltk.a -lXext -lXft -lfontconfig -lfontconfig -lXinerama -ldl -lm -lX11
The configure script of dillo uses "--ldflags", which is used for dynamic linking against "libfltk.so", while "--ldstaticflags" is used for linking against "libfltk.a". Which files of the two do you have in the respective directory (/usr/lib/x86_64-linux-gnu/)? My guess is that "libfltk.so" does not exist and so dillo is linked statically.
I do have both the dynamic and the static libraries:
$ ls /usr/lib/x86_64-linux-gnu/libfltk* /usr/lib/x86_64-linux-gnu/libfltk.a [..] /usr/lib/x86_64-linux-gnu/libfltk.so /usr/lib/x86_64-linux-gnu/libfltk.so.1.3
X11 is needed in src/xembed.cc. It seems that on most systems it is linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others not, so that an additional "-lX11" is necessary. Should we add it generally? It does not harm; we have only to care about other systems than X11. Sebastian
On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote:
On Sat, May 11, August Karlstrom wrote:
Linking with libX11 is what's missing:
LIBS=-lX11 ./configure make make install
This means that libX11 needs to be added to the build scripts.
On Mon, May 13, August Karlstrom wrote:
This is what I get:
$ fltk-config --ldflags -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk $ fltk-config --ldstaticflags -Wl,-Bsymbolic-functions /usr/lib/x86_64-linux-gnu/libfltk.a -lXext -lXft -lfontconfig -lfontconfig -lXinerama -ldl -lm -lX11
The configure script of dillo uses "--ldflags", which is used for dynamic linking against "libfltk.so", while "--ldstaticflags" is used for linking against "libfltk.a". Which files of the two do you have in the respective directory (/usr/lib/x86_64-linux-gnu/)? My guess is that "libfltk.so" does not exist and so dillo is linked statically.
I do have both the dynamic and the static libraries:
$ ls /usr/lib/x86_64-linux-gnu/libfltk* /usr/lib/x86_64-linux-gnu/libfltk.a [..] /usr/lib/x86_64-linux-gnu/libfltk.so /usr/lib/x86_64-linux-gnu/libfltk.so.1.3
X11 is needed in src/xembed.cc. It seems that on most systems it is linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others not, so that an additional "-lX11" is necessary. Should we add it generally? It does not harm; we have only to care about other systems than X11.
Could we check for libX11 in configure and link explicitely against it if available but not fail otherwise? That way dillo should still compile on OSX. Johannes
On Sat, May 18, Johannes Hofmann wrote:
On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote:
[...]
X11 is needed in src/xembed.cc. It seems that on most systems it is linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others not, so that an additional "-lX11" is necessary. Should we add it generally? It does not harm; we have only to care about other systems than X11.
Could we check for libX11 in configure and link explicitely against it if available but not fail otherwise? That way dillo should still compile on OSX.
I thought of this. The code is included in "#ifdef X_PROTOCOL", so making "-lX11" depend on this X_PROTOCOL should be save; however, I've not found where X_PROTOCOL is defined. Sebastian
On Sat, May 18, 2013 at 08:23:34PM +0200, Sebastian Geerken wrote:
On Sat, May 18, Johannes Hofmann wrote:
On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote:
[...]
X11 is needed in src/xembed.cc. It seems that on most systems it is linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others not, so that an additional "-lX11" is necessary. Should we add it generally? It does not harm; we have only to care about other systems than X11.
Could we check for libX11 in configure and link explicitely against it if available but not fail otherwise? That way dillo should still compile on OSX.
I thought of this. The code is included in "#ifdef X_PROTOCOL", so making "-lX11" depend on this X_PROTOCOL should be save; however, I've not found where X_PROTOCOL is defined.
That comes from the fltk headers depending on whether fltk was built with X11 backend or not. I don't see how we could get that information at configure time. Maybe some fltk-config option? Johannes
On Sat, May 18, Johannes Hofmann wrote:
On Sat, May 18, 2013 at 08:23:34PM +0200, Sebastian Geerken wrote:
On Sat, May 18, Johannes Hofmann wrote:
On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote:
[...]
X11 is needed in src/xembed.cc. It seems that on most systems it is linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others not, so that an additional "-lX11" is necessary. Should we add it generally? It does not harm; we have only to care about other systems than X11.
Could we check for libX11 in configure and link explicitely against it if available but not fail otherwise? That way dillo should still compile on OSX.
I thought of this. The code is included in "#ifdef X_PROTOCOL", so making "-lX11" depend on this X_PROTOCOL should be save; however, I've not found where X_PROTOCOL is defined.
That comes from the fltk headers depending on whether fltk was built with X11 backend or not.
Do not find it, strange.
I don't see how we could get that information at configure time. Maybe some fltk-config option?
See attached patch for an incomplete implementation. On my system, it says "checking whether to link to X11... yes", on OSX it should say "... no". Unfortunately, AC_RUN_IFELSE is incompatible with cross compiling. Perhaps, something with AC_COMPILE_IFELSE could also work. Sebastian
On Sat, May 18, 2013 at 09:59:18PM +0200, Sebastian Geerken wrote:
On Sat, May 18, Johannes Hofmann wrote:
On Sat, May 18, 2013 at 08:23:34PM +0200, Sebastian Geerken wrote:
On Sat, May 18, Johannes Hofmann wrote:
On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote:
[...]
X11 is needed in src/xembed.cc. It seems that on most systems it is linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others not, so that an additional "-lX11" is necessary. Should we add it generally? It does not harm; we have only to care about other systems than X11.
Could we check for libX11 in configure and link explicitely against it if available but not fail otherwise? That way dillo should still compile on OSX.
I thought of this. The code is included in "#ifdef X_PROTOCOL", so making "-lX11" depend on this X_PROTOCOL should be save; however, I've not found where X_PROTOCOL is defined.
That comes from the fltk headers depending on whether fltk was built with X11 backend or not.
Do not find it, strange.
Sorry, it's not in the fltk headers, but via fltk headers. It's defined in X11/X.h.
I don't see how we could get that information at configure time. Maybe some fltk-config option?
See attached patch for an incomplete implementation. On my system, it says "checking whether to link to X11... yes", on OSX it should say "... no".
Unfortunately, AC_RUN_IFELSE is incompatible with cross compiling. Perhaps, something with AC_COMPILE_IFELSE could also work.
Sebastian
diff -r 2a024fd43fe8 configure.ac --- a/configure.ac Sat May 18 21:27:59 2013 +0200 +++ b/configure.ac Sat May 18 21:58:45 2013 +0200 @@ -124,6 +124,28 @@ AC_MSG_ERROR(FLTK 1.3 required; fltk-config not found) esac
+dnl ----------------------------------- +dnl Test for X11 (only on some systems) +dnl ----------------------------------- +AC_MSG_CHECKING([whether to link to X11]) +AC_LANG_PUSH([C++]) +old_libs=$LIBS +old_cxxflags=$CXXFLAGS +LIBS=$LIBFLTK_LIBS +CXXFLAGS=$LIBFLTK_CXXFLAGS +AC_RUN_IFELSE([AC_LANG_PROGRAM([[ +#define FL_INTERNALS +#include <FL/x.H> +]],[[ +#ifdef X_PROTOCOL + return 0; +#else + return 1; +#endif +]])], [AC_MSG_RESULT(yes)] ,[AC_MSG_RESULT(no)]) +CXXFLAGS=$old_cxxflags +LIBS=$old_libs +AC_LANG_POP([C++])
dnl ---------------- dnl Test for libjpeg
Ah that's cool. It's good to base the decision for linking and the ifdef in the code on the same thing. I can test it on OSX on tuesday. Johannes
On Sat, May 18, 2013 at 09:59:18PM +0200, Sebastian Geerken wrote:
On Sat, May 18, Johannes Hofmann wrote:
On Sat, May 18, 2013 at 08:23:34PM +0200, Sebastian Geerken wrote:
On Sat, May 18, Johannes Hofmann wrote:
On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote:
[...]
X11 is needed in src/xembed.cc. It seems that on most systems it is linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others not, so that an additional "-lX11" is necessary. Should we add it generally? It does not harm; we have only to care about other systems than X11.
Could we check for libX11 in configure and link explicitely against it if available but not fail otherwise? That way dillo should still compile on OSX.
I thought of this. The code is included in "#ifdef X_PROTOCOL", so making "-lX11" depend on this X_PROTOCOL should be save; however, I've not found where X_PROTOCOL is defined.
That comes from the fltk headers depending on whether fltk was built with X11 backend or not.
Do not find it, strange.
I don't see how we could get that information at configure time. Maybe some fltk-config option?
See attached patch for an incomplete implementation. On my system, it says "checking whether to link to X11... yes", on OSX it should say "... no".
Yes, works ok on OSX: checking for socklen_t... socklen_t checking FLTK 1.3... yes checking whether to link to X11... no Cheers, Johannes
On Wed, May 22, Johannes Hofmann wrote:
On Sat, May 18, 2013 at 09:59:18PM +0200, Sebastian Geerken wrote:
On Sat, May 18, Johannes Hofmann wrote:
On Sat, May 18, 2013 at 08:23:34PM +0200, Sebastian Geerken wrote:
On Sat, May 18, Johannes Hofmann wrote:
On Sat, May 18, 2013 at 02:47:56PM +0200, Sebastian Geerken wrote:
[...]
X11 is needed in src/xembed.cc. It seems that on most systems it is linked indirectly, (src/dillo -> libfltk.so -> libX11.so), on others not, so that an additional "-lX11" is necessary. Should we add it generally? It does not harm; we have only to care about other systems than X11.
Could we check for libX11 in configure and link explicitely against it if available but not fail otherwise? That way dillo should still compile on OSX.
I thought of this. The code is included in "#ifdef X_PROTOCOL", so making "-lX11" depend on this X_PROTOCOL should be save; however, I've not found where X_PROTOCOL is defined.
That comes from the fltk headers depending on whether fltk was built with X11 backend or not.
Do not find it, strange.
I don't see how we could get that information at configure time. Maybe some fltk-config option?
See attached patch for an incomplete implementation. On my system, it says "checking whether to link to X11... yes", on OSX it should say "... no".
Yes, works ok on OSX:
checking for socklen_t... socklen_t checking FLTK 1.3... yes checking whether to link to X11... no
Good. I've extended it and it is now in the repository. When cross-compiling (has anyone tested this?), nothing should change. August: Please test whether the version from the repository works for you. Sebastian
On 2013-05-22 15:33, Sebastian Geerken wrote: [...]
August: Please test whether the version from the repository works for you.
I still get an error when compiling Dillo (version 2013-05-22, changeset 2843:60a7bb6ca06b): $ make ... g++ -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/freetype2 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dw-anchors-test dw_anchors_test.o ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk /usr/bin/ld: ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): undefined reference to symbol 'XCreatePixmap' /usr/bin/ld: note: 'XCreatePixmap' is defined in DSO /usr/lib/x86_64-linux-gnu/libX11.so.6 so try adding it to the linker command line /usr/lib/x86_64-linux-gnu/libX11.so.6: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[2]: *** [dw-anchors-test] Error 1 make[2]: Leaving directory `/tmp/dillo3/test' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/dillo3' make: *** [all] Error 2 Apparently -lX11 has not been added. Although I don't see how that would make a difference I can also mention that I start X Windows (Blackbox WM) from the console with the startx command without using a display manager. Regards, August
On Thu, May 23, August Karlstrom wrote:
On 2013-05-22 15:33, Sebastian Geerken wrote: [...]
August: Please test whether the version from the repository works for you.
I still get an error when compiling Dillo (version 2013-05-22, changeset 2843:60a7bb6ca06b):
$ make ... g++ -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/freetype2 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dw-anchors-test dw_anchors_test.o ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk /usr/bin/ld: ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): undefined reference to symbol 'XCreatePixmap' /usr/bin/ld: note: 'XCreatePixmap' is defined in DSO /usr/lib/x86_64-linux-gnu/libX11.so.6 so try adding it to the linker command line /usr/lib/x86_64-linux-gnu/libX11.so.6: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[2]: *** [dw-anchors-test] Error 1 make[2]: Leaving directory `/tmp/dillo3/test' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/dillo3' make: *** [all] Error 2
Apparently -lX11 has not been added. Although I don't see how that would make a difference I can also mention that I start X Windows (Blackbox WM) from the console with the startx command without using a display manager.
Startx instead of xdm should not make a difference. Did you call "autogen.sh" again before "configure"? To get more informations: what is the output of "configure"? Or, better, send the your "config.log". Sebastian
On 2013-05-23 22:02, Sebastian Geerken wrote:
Did you call "autogen.sh" again before "configure"?
Yes, I followed the instructions at http://www.dillo.org/source.html.
To get more informations: what is the output of "configure"? Or, better, send the your "config.log".
OK, I have attached config.log. /August
Hi! Is there anything new on this topic? On Sat, May 25, 2013, August Karlstrom wrote:
On 2013-05-23 22:02, Sebastian Geerken wrote:
Did you call "autogen.sh" again before "configure"?
Yes, I followed the instructions at http://www.dillo.org/source.html.
To get more informations: what is the output of "configure"? Or, better, send the your "config.log".
OK, I have attached config.log.
The config.log looks OK, the value of LIBX11_LIBS is set. Is it also set in Makefile, Makefile.in, src/Makefile, src/Makefile.in? In all files, there should be the line LIBX11_LIBS = @LIBX11_LIBS@ (Makefile.in) LIBX11_LIBS = -lX11 (Makefile) Futhermore, part of "dillo_LDADD" should be "@LIBX11_LIBS@" in src/Makefile.in, and "-lX11" in src/Makefile. Please check this. What version of automake do you use? According to config.log, your autoconf version is 2.69. OTOH, I must admit that my autoconf/automake knowledge is limited, so perhaps someone else may help here. Sebastian
On 2013-06-14 11:26, Sebastian Geerken wrote:
Hi!
Is there anything new on this topic?
On Sat, May 25, 2013, August Karlstrom wrote:
On 2013-05-23 22:02, Sebastian Geerken wrote:
Did you call "autogen.sh" again before "configure"?
Yes, I followed the instructions at http://www.dillo.org/source.html.
To get more informations: what is the output of "configure"? Or, better, send the your "config.log".
OK, I have attached config.log.
The config.log looks OK, the value of LIBX11_LIBS is set. Is it also set in Makefile, Makefile.in, src/Makefile, src/Makefile.in? In all files, there should be the line
LIBX11_LIBS = @LIBX11_LIBS@ (Makefile.in)
LIBX11_LIBS = -lX11 (Makefile)
Yes, it is set in all files you mention: $ grep LIBX11_LIBS Makefile LIBX11_LIBS = -lX11 $ grep LIBX11_LIBS Makefile.in LIBX11_LIBS = @LIBX11_LIBS@ $ grep LIBX11_LIBS src/Makefile LIBX11_LIBS = -lX11 $ grep LIBX11_LIBS src/Makefile.in LIBX11_LIBS = @LIBX11_LIBS@ @LIBICONV_LIBS@ @LIBPTHREAD_LIBS@ @LIBX11_LIBS@
Futhermore, part of "dillo_LDADD" should be "@LIBX11_LIBS@" in src/Makefile.in, and "-lX11" in src/Makefile. Please check this.
Yes, these strings are also present: $ grep -m1 -A9 dillo_LDADD src/Makefile.in dillo_LDADD = \ $(top_builddir)/dlib/libDlib.a \ $(top_builddir)/dpip/libDpip.a \ IO/libDiof.a \ $(top_builddir)/dw/libDw-widgets.a \ $(top_builddir)/dw/libDw-fltk.a \ $(top_builddir)/dw/libDw-core.a \ $(top_builddir)/lout/liblout.a \ @LIBJPEG_LIBS@ @LIBPNG_LIBS@ @LIBFLTK_LIBS@ @LIBZ_LIBS@ \ @LIBICONV_LIBS@ @LIBPTHREAD_LIBS@ @LIBX11_LIBS@ $ grep -m1 -A9 dillo_LDADD src/Makefile dillo_LDADD = \ $(top_builddir)/dlib/libDlib.a \ $(top_builddir)/dpip/libDpip.a \ IO/libDiof.a \ $(top_builddir)/dw/libDw-widgets.a \ $(top_builddir)/dw/libDw-fltk.a \ $(top_builddir)/dw/libDw-core.a \ $(top_builddir)/lout/liblout.a \ -ljpeg -L/usr/lib/x86_64-linux-gnu -lpng12 -lpng12 -L/usr/lib/x86_64-linux-gnu -Wl,-Bsymbolic-functions -lfltk -lz \ -lpthread -lX11
What version of automake do you use? According to config.log, your autoconf version is 2.69.
I use automake 1.11.6 Thanks for your help Sebastian. Regards, August
participants (7)
-
abe＠deuxchevaux.org -
furaisanjin＠gmail.com -
fusionfile＠gmail.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
johannes.hofmann＠gmx.de
-
sgeerken＠dillo.org