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 -l<foo>, 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.1&view=markup [3] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/native-cctools/files/aix-2/mkexpfile?revision=1.1&view=markup [4] http://sourceforge.net/p/gentooprefixtree/code/ci/23181bf2b106f56e25446acb519563e19fb5747c/tree/sys-libs/readline/files/readline-6.2-aixso.patch /haubi/
