Re: [PATCH] ltdl: set libltdl_cv_need_uscore to yes on OS/2
Hi/2. Gary V. Vaughan wrote: Hi, Thanks for the report and the patch! On Nov 22, 2014, at 4:08 AM, KO Myung-Hun kom...@gmail.com wrote: On OS/2, dlopen() does not support a program. So libltdl_cv_need_uscore is set to unknown, but dlsym() requires an underscore prefix. So set libltdl_cv_need_uscore to yes on OS/2 if lt_cv_sys_symbol_underscore is yes and libltdl_cv_need_uscore is unknown. Actually, I think the real problem here is that LT_FUNC_DLSYM_USCORE is making the bad assumption that dlsym() only requires a leading symbol name underscore on machines where self dlopening works. Better than your suggested patch, we should really be checking whether dlsym of ordinary loadable module symbol names requires a leading underscore. I agree. I pushed the core of a new macro that does exactly that to M4 master just now. Would you let me know whether this works correctly on OS2 for you please? Of course. Unfortunately, however, it does not work. dlopen() in configure fails due to 'file not found'. -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM Korean OS/2 User Community : http://www.ecomstation.co.kr
Re: [PATCH] ltdl: set libltdl_cv_need_uscore to yes on OS/2
Hi! On 27 Nov 2014, at 02:47, KO Myung-Hun kom...@gmail.com wrote: Hi/2. Gary V. Vaughan wrote: Hi, Thanks for the report and the patch! On Nov 22, 2014, at 4:08 AM, KO Myung-Hun kom...@gmail.com wrote: On OS/2, dlopen() does not support a program. So libltdl_cv_need_uscore is set to unknown, but dlsym() requires an underscore prefix. So set libltdl_cv_need_uscore to yes on OS/2 if lt_cv_sys_symbol_underscore is yes and libltdl_cv_need_uscore is unknown. Actually, I think the real problem here is that LT_FUNC_DLSYM_USCORE is making the bad assumption that dlsym() only requires a leading symbol name underscore on machines where self dlopening works. Better than your suggested patch, we should really be checking whether dlsym of ordinary loadable module symbol names requires a leading underscore. I agree. I pushed the core of a new macro that does exactly that to M4 master just now. Would you let me know whether this works correctly on OS2 for you please? Of course. Unfortunately, however, it does not work. dlopen() in configure fails due to 'file not found'. Thanks for checking. Can you tell me why it fails (module is not compiled correctly; path argument to dlopen() is wrong), and maybe suggest what would fix it, please? Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: [PATCH] ltdl: set libltdl_cv_need_uscore to yes on OS/2
Hi/2. Gary V. Vaughan wrote: Hi! On 27 Nov 2014, at 02:47, KO Myung-Hun kom...@gmail.com wrote: Hi/2. Gary V. Vaughan wrote: Hi, Thanks for the report and the patch! On Nov 22, 2014, at 4:08 AM, KO Myung-Hun kom...@gmail.com wrote: On OS/2, dlopen() does not support a program. So libltdl_cv_need_uscore is set to unknown, but dlsym() requires an underscore prefix. So set libltdl_cv_need_uscore to yes on OS/2 if lt_cv_sys_symbol_underscore is yes and libltdl_cv_need_uscore is unknown. Actually, I think the real problem here is that LT_FUNC_DLSYM_USCORE is making the bad assumption that dlsym() only requires a leading symbol name underscore on machines where self dlopening works. Better than your suggested patch, we should really be checking whether dlsym of ordinary loadable module symbol names requires a leading underscore. I agree. I pushed the core of a new macro that does exactly that to M4 master just now. Would you let me know whether this works correctly on OS2 for you please? Of course. Unfortunately, however, it does not work. dlopen() in configure fails due to 'file not found'. Thanks for checking. Can you tell me why it fails (module is not compiled correctly; path argument to dlopen() is wrong), and maybe suggest what would fix it, please? I've look into this problem. Module is not built. To build it, some additional variables are required. They are soname, libname, output_objdir. And archive_cmds on OS/2 consists of multi lines separated by ~. So when using it, quotation is needed. And to eval it the function such as func_execute_cmds is needed. In addition, make sure .libs exist before building a module. Finally, please remember that OS/2 does not support DLLs whose base name is longer than 8 characters. Thanks. -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM Korean OS/2 User Community : http://www.ecomstation.co.kr
libtool problem with --whole-archive/--no-whole-archive
Hi All, For our project we use automake/libtool automake (GNU automake) 1.14.1 libtool (GNU libtool) 2.4.2 autoconf (GNU Autoconf) 2.69 We have, platform/targetA/Makefile.am platform/targetB/Makefile.am example/*/Makefile.am We wanted to link an external lib wrapped around --whole-archive/--no-whole-archive with the example application as given below, platform/targetA/Makefile.am LIBS += -Wl,--whole-archive LIBS += -lmyextlib LIBS += -Wl,--no-whole-archive Problem is, platform linker command doesn't have --whole-archive/--no-whole-archive around the lib. Instead it comes later in the command line. gcc: -Wl,--whole-archive -lmyextlib -ldl -Wl,--no-whole-archive libtool link: -lrt -lcrypto -lmyextlib -ldl -pthread -O2 -pthread -Wl,--whole-archive -Wl,--no-whole-archive example/*/Makefile.am When compiling the example app, linker command line just has -lmyextlib and doesn't have --whole-archive/--no-whole-archive at all. How to propogate the --whole-archive/--no-whole-archive all the way down to example app linking?. Importantly, it should be around the -lmyextlib. I can make changes only at platform/targetA/Makefile.am as example/* is common across all other platforms. Note: Tried libtool's suggestion of -Wl,'-whole-archive -lfoo -no-whole-archive' as mentioned in lists.gnu.org/archive/html/libtool/2002-05/msg00043.html but that didn't work. Am I missing something here? What I am trying to achieve is completely wrong? Thanks, Venkatesh. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] fix bootstrapping and module loading (was: [PATCH] build: fix bootstrapping)
Hi Pavel, On Nov 22, 2014, at 7:28 AM, Pavel Raiskup prais...@redhat.com wrote: On Friday 21 of November 2014 19:31:51 Gary V. Vaughan wrote: Starting slowly, your first patch conflates two separate changes. The first of those bringing back the correct use of LT_LIB_DLLOAD so that LIBADD_DL is set correctly for Makefile.in. That seems slightly wrong to me, because master has not used libltdl for a while. I've added the macro, but instead of removing LIBADD_DL from the link libraries, I removed LIBLTDL. ACK for LIBLTDL removal from m4_libm4_la_LIBADD. However to my previous patch this is different change. This is nit, but I removed the LIBADD_DL in hope that it is not needed; LT_LIB_DLLOAD already puts '-ldl' into LIBS for me: I think that's a bug. 2 bugs in fact: 1. LIBADD_DL is not documented, so M4 should be using LIBADD_DLOPEN. 2. LT_LIB_DLLOAD is not restoring LIB to its pristine state after calling AC_SEARCH_LIBS, so the additional `-ldl` should not be there. /bin/sh ./libtool --tag=CC --mode=link gcc -std=gnu99 -O0 -g3 -pipe -no-undefined -export-dynamic -export-symbols-regex .* -o m4/libm4.la -rpath /usr/local/lib m4/builtin.lo m4/debug.lo m4/hash.lo m4/input.lo m4/m4.lo m4/macro.lo m4/module.lo m4/output.lo m4/path.lo m4/resyntax.lo m4/symtab.lo m4/syntax.lo m4/utility.lo m4/gnu/libgnu.la -ldl -ldl ^^ I'm testing patches for both, though you'll still see the duplicate -ldl in the link line except when rebootstrapping with master (and imminent 2.4.4) libtool. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) ___ https://lists.gnu.org/mailman/listinfo/libtool
how does libtool order -Wl,--rpath?
Sorry to resurrect an old thread, but I just ran into the problem at https://lists.gnu.org/archive/html/libtool/2003-07/msg00062.html. Does anyone know libtool handles this? I'm trying to understand how a particular library that's installed on my system works, so I compiled a debug version and installed it into a folder in my home directory. However, whenever I use libtool to try to link with my debug version, it seems to always put /usr/local/lib at the front of the rpath. Is there some way to enforce ordering of the -Wl,-rpath arguments that libtool emits? I should note that all the necessary folders are in the rpath arguments; they're just in the wrong order. I know I can solve my problem with LD_LIBRARY_PATH, but I'm trying to find a solution that doesn't require this. Thanks, Myles ___ https://lists.gnu.org/mailman/listinfo/libtool
