-- Originally posted by (AT sourceforge.net): yselkowitz -- -- This ticket was imported from http://sourceforge.net/p/rkward/bugs/52 on 2017-05-30 15:26:38 +0100 -- Building 0.5.1 for X11, the link fails due to undefined symbols in rkward.bin which need to be resolved by adding -lX11 \(X11\_X11\_LIB in CMake parlance\). Patch attached.
-- Originally posted by (AT sourceforge.net): yselkowitz -- X11_X11_LIB patch -- Created an attachment --
Thanks for the patch. Committed to SVN \(slightly modified, so -lX11 is not used on Windows\). While it really is correct to link against X11, this used to work without explicitly adding -X11, and still does on this system. Could you give some details on the system\(s\) where linking fails without this? Depending on just how common that is, we might need a bugfix release, that's why I'm asking. Regards Thomas
- **assigned_to**: nobody --> tfry - **status**: open --> open-fixed
-- Originally posted by (AT sourceforge.net): yselkowitz -- On PE/COFF platforms, such as native Windows/MinGW and Cygwin, all symbols must be resolved at link time. ELF binaries do not have this limitation unless -Wl,--no-undefined \(aka -Wl,-z,defs\) is used, hence it works regardless. There are explicit calls to XInternAtom and XSelectInput in rkwardapplication.cpp \(ifndef Q\_WS\_WIN, of course\). Cygwin is a PE/COFF platform but uses \*NIX/X11 APIs, hence the problem. \(On Linux, there is technically the extra time involved in ld.so resolving those symbols at runtime, but given that libX11 would already be loaded I highly doubt that it would be noticeable.\) AFAICS there is no rush to release just for this.
Thanks for explaining. Well, again, I've changed this in SVN, so closing the report.
- **status**: open-fixed --> closed-fixed