Re: [PATCH] AIX SONAME emulation, simplified implementation
Hi... From: michael.haubenwall...@ssi-schaefer.com At: Jul 7 2015 11:30:17 To: Daniel Ruoso (BLOOMBERG/ 731 LEX) Cc: dan...@ruoso.com, libtool-patches@gnu.org Subject: Re: [PATCH] AIX SONAME emulation, simplified implementation For non-libtool build systems: Have you considered to add (optional) libtool support instead of implementing sharedlib details? This does not mean to completely libtoolize, but to use the (separate) libtool script[1] as the compiler/linker - something like: What we have been doing in cases like this is to generate everything after the fact (and sometimes re-invoke the linker for case of transitive dependencies inside a single project. This without any change whatsoever to the actual source code of the project. In other cases (mysql, for instance), there is already some support for generating the export file for Windows builds, in which case it's trivial to trick the build system into implementing the simplified SONAME emulation. I'll investigate how hard would it be to use your version of it for libtool projects (even if I still do the simplified version for hand-rolled build systems). I've experienced that there isn't so much difference adding svr4-mode to whatever build system compared to adding simple-mode, given that you have to non-trivially touch that build system anyway. That's the thing, implementing the simple-mode from outside the build system works trivially on almost every case. When there is transitive dependencies inside a project it requires a bit more work, but in general I don't have to patch anything. OTOH, once I've wrapped[2] the ld command to accept the '-soname' flag. Combined with an mkexpfile[3] command to get the exported symbols right, the diff for any build system can become quite small[4]. [2] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/native-cctools/files/aix-2/ld?revision=1.1view=markup [3] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/native-cctools/files/aix-2/mkexpfile?revision=1.1view=markup [4] http://sourceforge.net/p/gentooprefixtree/code/ci/23181bf2b106f56e25446acb519563e19fb5747c/tree/sys-libs/readline/files/readline-6.2-aixso.patch Hah, I think we are doing the same thing in different ways, you're using Gentoo and I'm using Debian as the base for maintaining a collection of software on top of a foreign environment.
Re: [PATCH] AIX SONAME emulation, simplified implementation
Hi Daniel, On 07/07/2015 04:30 PM, Daniel Ruoso (BLOOMBERG/ 731 LEX) wrote: From: michael.haubenwall...@ssi-schaefer.com At: Jul 6 2015 10:50:50 On 06/24/2015 03:34 PM, Daniel Ruoso (BLOOMBERG/ 731 LEX) wrote: This patch offers a simplified implementation of a SONAME-like behavior emulation. I've tried this variant of soname-emulation too, but discovered the one using the lib.so.v(shr.o,shr.imp) archive (=svr4) as the more reasonable compromise. Is there a specific reason you need/want this simplified implementation? The main reason is actually non-libtool build systems, where I have to implement this by hand. The .so as text file is a much simpler implementation for situations where I have to torture a hand-rolled build-system into producing a versionable shared object. For non-libtool build systems: Have you considered to add (optional) libtool support instead of implementing sharedlib details? This does not mean to completely libtoolize, but to use the (separate) libtool script[1] as the compiler/linker - something like: LIBRARY = libNAME.la OBJS = *.lo CC = libtool --mode=compile --tag=CC gcc CXX = libtool --mode=compile --tag=CXX g++ LD = libtool --mode=link --tag=CXX g++ [1] https://github.com/haubi/host-libtool/ This is different in the sense that it doesn't add archives disguised as .so files, Yeah, instead it does provide plain text files disguised as .so files. Besides that, there's potential for more different confusion: *) Linking with /path/to/lib.so produces different result than linking with /path/to/lib.so.v (difference is in the runpath). *) dlopen(lib.so) fails, while dlopen(lib.so.v) does work. *) Provides two distinct files, instead of one single file with symlinks. Those are fair points, I haven't considered them since all my AIX builds happen in very controlled setups. Even controlled setups can be portable... I could maybe argue that the dlopen case is a degenerate case, because the runtime interface of a versioned shared library is its SONAME, not the unversioned .so, Agreed. and for shared objects that are intended to be dlopen'ed (which libtool calls modules), my patch won't affect them. and instead relies on the fact that the AIX linker will take an import file when looking for -lfoo, and will record what the import file says. This very detail isn't anything different compared to aix-soname=svr4. Fair point again... I think the main problem is that we implemented this patches in parallel, but I forgot to release mine for a long time, and you did a much better job at it :). Thank you! ;) I'll investigate how hard would it be to use your version of it for libtool projects (even if I still do the simplified version for hand-rolled build systems). I've experienced that there isn't so much difference adding svr4-mode to whatever build system compared to adding simple-mode, given that you have to non-trivially touch that build system anyway. OTOH, once I've wrapped[2] the ld command to accept the '-soname' flag. Combined with an mkexpfile[3] command to get the exported symbols right, the diff for any build system can become quite small[4]. [2] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/native-cctools/files/aix-2/ld?revision=1.1view=markup [3] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/native-cctools/files/aix-2/mkexpfile?revision=1.1view=markup [4] http://sourceforge.net/p/gentooprefixtree/code/ci/23181bf2b106f56e25446acb519563e19fb5747c/tree/sys-libs/readline/files/readline-6.2-aixso.patch /haubi/
Re: [PATCH] AIX SONAME emulation, simplified implementation
From: michael.haubenwall...@ssi-schaefer.com At: Jul 6 2015 10:50:50 To: Daniel Ruoso (BLOOMBERG/ 731 LEX) Cc: libtool-patches@gnu.org Subject: Re: [PATCH] AIX SONAME emulation, simplified implementation On 06/24/2015 03:34 PM, Daniel Ruoso (BLOOMBERG/ 731 LEX) wrote: This patch offers a simplified implementation of a SONAME-like behavior emulation. I've tried this variant of soname-emulation too, but discovered the one using the lib.so.v(shr.o,shr.imp) archive (=svr4) as the more reasonable compromise. Is there a specific reason you need/want this simplified implementation? The main reason is actually non-libtool build systems, where I have to implement this by hand. The .so as text file is a much simpler implementation for situations where I have to torture a hand-rolled build-system into producing a versionable shared object. This is different in the sense that it doesn't add archives disguised as .so files, Yeah, instead it does provide plain text files disguised as .so files. Besides that, there's potential for more different confusion: *) Linking with /path/to/lib.so produces different result than linking with /path/to/lib.so.v (difference is in the runpath). *) dlopen(lib.so) fails, while dlopen(lib.so.v) does work. *) Provides two distinct files, instead of one single file with symlinks. Those are fair points, I haven't considered them since all my AIX builds happen in very controlled setups. I could maybe argue that the dlopen case is a degenerate case, because the runtime interface of a versioned shared library is its SONAME, not the unversioned .so, and for shared objects that are intended to be dlopen'ed (which libtool calls modules), my patch won't affect them. and instead relies on the fact that the AIX linker will take an import file when looking for -lfoo, and will record what the import file says. This very detail isn't anything different compared to aix-soname=svr4. Fair point again... I think the main problem is that we implemented this patches in parallel, but I forgot to release mine for a long time, and you did a much better job at it :). I'll investigate how hard would it be to use your version of it for libtool projects (even if I still do the simplified version for hand-rolled build systems). daniel
