Bug #41360 for ExtUtils-MakeMaker: ExtUtils::MakeMaker didn't recognize *.so under AIX (maybe other systems, too?)

Mon Dec 01 16:23:33 2008 REHSACK [...] cpan.org - Ticket created

Subject:

ExtUtils::MakeMaker didn't recognize *.so under AIX (maybe other systems, too?)

On AIX compiling with xlc I've seen, that sapnwrfc always failed to append -lsapnwrfc and -lsapucum. Both are binary shared objects delivered by SAP AG without a corresponding *.a. $Config{lib_ext} = '.a' --> don't find libsapnwrfc.so I added a patch which looks for $thislib.$Config{dlext} - if $Config{dlext} defined ...

Subject:

patch-ae

Download patch-ae
application/octet-stream 1.1k

Message body not shown because it is not plain text.

Thu Apr 02 10:58:22 2009 mschwern [...] cpan.org - Correspondence added

On Mon Dec 01 16:23:33 2008, REHSACK wrote: Show quoted text

> On AIX compiling with xlc I've seen, that sapnwrfc always failed to > append -lsapnwrfc and -lsapucum. Both are binary shared objects > delivered by SAP AG without a corresponding *.a. > > $Config{lib_ext} = '.a' --> don't find libsapnwrfc.so > > I added a patch which looks for $thislib.$Config{dlext} - if > $Config{dlext} defined ...

I'm not sure this is the right thing to do. I don't really follow that code so well, but it doesn't appear to be much about shared libraries as it is about archives. Or something, I'm not much of a C programmer. I do know that on OS X $Config{lib_ext} is .a, $Config{so} is dylib and $Config{dlext} is bundle. What are your values? The code does check for $Config{so} so maybe that's missing?

Thu Apr 02 10:58:23 2009 The RT System itself - Status changed from 'new' to 'open'

Thu Apr 02 11:50:35 2009 mschwern [...] cpan.org - Status changed from 'open' to 'stalled'

Tue Jun 02 03:14:11 2009 REHSACK [...] cpan.org - Correspondence added

On Thu Apr 02 10:58:22 2009, MSCHWERN wrote: Show quoted text

> I'm not sure this is the right thing to do. I don't really follow that > code so well, but it doesn't appear to be much about shared libraries as > it is about archives.

AIX (and I don't know which other commercial UNIX, too) has (or supports, uses - insert what you want) "pseudo-dynamic" linking. That means, the /lib/libc.so you know from Linux, *BSD, ... is named on AIX /lib/libc.a - and yes, it contains *.o files which are used for dynamic linking. Show quoted text

> Or something, I'm not much of a C programmer.

Well, I am - and I was confused about that :) Show quoted text

> I do know that on OS X $Config{lib_ext} is .a, $Config{so} is dylib and > $Config{dlext} is bundle. What are your values? The code does check > for $Config{so} so maybe that's missing?

Do you want to receive the contents of $Config of an AIX system (maybe one per compiler?).

Tue Jun 02 03:14:12 2009 The RT System itself - Status changed from 'stalled' to 'open'

Thu Jul 30 03:42:36 2009 mschwern [...] cpan.org - Correspondence added

This is already being used in the wild with NetBSD?

Thu Jul 30 12:11:23 2009 rehsack [...] web.de - Correspondence added

Subject:	Re: [rt.cpan.org #41360] ExtUtils::MakeMaker didn't recognize *.so under AIX (maybe other systems, too?)
Date:	Thu, 30 Jul 2009 16:00:20 +0000
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Jens Rehsack <rehsack [...] web.de>

Michael G Schwern via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=41360 > > > This is already being used in the wild with NetBSD?

Yes - but with pkgsrc. Jens

Download signature.asc
application/pgp-signature 834b

Message body not shown because it is not plain text.

Thu Mar 04 08:50:30 2010 HMBRAND [...] cpan.org - Correspondence added

Jens asked me to post my opinions here ... I'll just paste the IRC log --8<--- Mar 01 15:00:22 <Tux> Sno|Laptop, I've so far ONLY seen .a on AIX Mar 01 15:00:31 <Tux> and AIX only has relocatable objects Mar 01 15:00:55 <Tux> (I'm not an AIX expert, and don't want to become one) Mar 01 15:02:11 <Tux> I don't think EU::MM (or any build tool) should try to support non-standard extensions Mar 01 15:02:32 <Tux> a symlink from .so => .a would most likely `fix' the problem Mar 01 15:03:13 <Tux> if SAP is so stupid to ship .so or .sl files where the rest of the world uses .a on that OS, it's their fault, not ours Mar 01 15:04:50 <Tux> I'm aware that braindead tools like libtool insist on createing libfoo.so.0.0.1.0 and then symlink libfoo.so to it Mar 01 15:05:01 <Tux> and then FORGET to symlink .a to it Mar 01 15:05:25 <Tux> but I consider libtool the ultimate counterproductive tool Mar 01 15:05:51 <Tux> it only works on Linux, and even then makes your life a lot harder than it should be Mar 01 15:06:01 <Tux> libtools sucks beyond belief Mar 01 15:08:56 <Sno|Laptop> Tux: AIX has both, .a and .so Mar 01 15:10:43 <Tux> I just checked on my AIX 5.3.0, and the .so's all come from stupidly built libtool projects Mar 01 15:10:48 <Tux> all others are .a Mar 01 15:11:02 <Tux> IMHO AIX should NEVER have .so Mar 01 15:11:18 <Sno|Laptop> .a are archives created from ar - they can contain shared objects Mar 01 15:11:29 <Tux> do you have an example (other than from open- source) where .so is shipped? Mar 01 15:11:59 <Sno|Laptop> no - and my patch in named RT enables EU::MM to use .a, too - not only .so Mar 01 15:12:17 <Tux> .a libraries/archives under AIX contain BOTH 32bit and 64bit objects Mar 01 15:12:37 <Tux> you need flags to see on what side you work Mar 01 15:12:42 <Sno|Laptop> but it should be able to use .so, too - because it should be able to link open source and closed source libraries :) Mar 01 15:13:02 <Tux> that makes it extremely hard to see from the outside if you can use the archive at all Mar 01 15:13:43 <Sno|Laptop> on AIX you can nearly always link against .a - and that enables the patch I submitted Mar 01 15:13:59 <Tux> IMHO open-source project should deliver the archives/libraries in the format required by the oS, and not blindly follow their own flawed view Mar 01 15:15:08 <Sno|Laptop> you're right - in principle Mar 01 15:15:10 <Tux> example: using libtool makes it impossible to build the same project twice and generate a library that contains both 32bit and 64bit objects Mar 01 15:15:43 <Tux> you have to build it for 32bit, save the library, then build it for 64bit, save the library and merge those by hand Mar 01 15:15:43 <Sno|Laptop> no - have a look into the .a files Mar 01 15:15:59 <Tux> libtool should, but doesn't Mar 01 15:16:03 <Sno|Laptop> there're two shared objects in it: obj.o and obj_64.o Mar 01 15:16:24 <Sno|Laptop> both are shared objects (build like libtool would) and combined into one .a Mar 01 15:16:38 <Tux> no, mostly they have the same name, but identify by -X64 or $OBJECT_MODE Mar 01 15:17:40 <Sno|Laptop> 'ar t -X32_64 xx.a' shows both :) Mar 01 15:18:02 <Tux> libc.a is one of the exceptions where obj.o and obj_64.o have different names Mar 01 15:19:32 <Sno|Laptop> but let me quote xdg: <@xdg> Sno| Laptop, Perl has a long history of not breaking things for legacy users. Mar 01 15:19:33 <Tux> $ ar -X32 tv libpcre.a pcre_exec.o Mar 01 15:19:33 <Tux> rw-rw-rw- 203/200 49917 Apr 20 09:27 2009 pcre_exec.o Mar 01 15:19:33 <Tux> $ ar -X64 tv libpcre.a pcre_exec.o Mar 01 15:19:33 <Tux> rw-rw-rw- 203/200 57476 Apr 20 09:36 2009 pcre_exec.o Mar 01 15:20:15 <Tux> $ ar -X32_64 tv libpcre.a pcre_exec.o Mar 01 15:20:15 <Tux> rw-rw-rw- 203/200 57476 Apr 20 09:36 2009 pcre_exec.o Mar 01 15:20:21 <Tux> Only one Mar 01 15:21:32 <Tux> FWIW I'm not opposing to patch whatever to support both unless it causes extreme pain Mar 01 15:21:49 <Tux> if you convince Schwern to support both, that is ok with me Mar 01 15:22:56 <Sno|Laptop> he just wants someone to review it if it could break sth. Mar 01 15:24:10 <Tux> ah Mar 01 15:31:19 <Sno|Laptop> I (meanwhile) don't know the history anymore ... Mar 01 15:31:41 <Sno|Laptop> but there were XS modules which failed linking on AIX without this patch -->8---

Thu Mar 04 16:26:20 2010 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #41360] ExtUtils::MakeMaker didn't recognize *.so under AIX (maybe other systems, too?)
Date:	Thu, 04 Mar 2010 13:25:21 -0800
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

H.Merijn Brand via RT wrote: Show quoted text

> Mar 01 15:21:32 <Tux> FWIW I'm not opposing to patch whatever to > support both unless it causes extreme pain > Mar 01 15:21:49 <Tux> if you convince Schwern to support both, that > is ok with me > Mar 01 15:22:56 <Sno|Laptop> he just wants someone to review it if > it could break sth. > Mar 01 15:24:10 <Tux> ah > Mar 01 15:31:19 <Sno|Laptop> I (meanwhile) don't know the history > anymore ... > Mar 01 15:31:41 <Sno|Laptop> but there were XS modules which failed > linking on AIX without this patch

What I got out of this is "libtool is not being polite" but that's hardly the end user's fault. What I didn't get out of it is GIVEN libtool is pooping .so files around, whether the patch is a good idea. I'm at the point where I'm happy to apply it if Sno is happy to fix it when it breaks. -- Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml

Fri Mar 05 01:03:44 2010 REHSACK [...] cpan.org - Correspondence added

On Thu Mar 04 16:26:20 2010, schwern@pobox.com wrote: Show quoted text

> I'm at the point where I'm happy to apply it if Sno is happy to fix it > when it breaks.

Sure

Fri Mar 05 04:17:00 2010 mschwern [...] cpan.org - Correspondence added

Its in as 43b4e9e

Fri Mar 05 04:17:02 2010 mschwern [...] cpan.org - Status changed from 'open' to 'resolved'