Re: [Chicken-hackers] ATTN solaris users -- [PATCH] Apply the same naming scheme for .so libs in "libs" target

[Jim Ursetto]

I'm going to hypothesize this broke Solaris as well.  I believe in previous 
versions it created both a 'libchicken.so' and a 'libchicken.so.6' -- the 
latter one being never used.  Now it should create only 'libchicken.so.7', 
which the Solaris linker should not be able to find (or it will use the old 
one).

I'd appreciate it if a nice Solaris user could check something for me:

1) In Chicken <= 4.8.0.3, whether libchicken.so and libchicken.so.6 both exist 
in the install directory,
   and are both regular files, not symlinks.
   Probably `ls -l /usr/local/lib/libchicken.so*` will do the trick.

2) In Chicken built from master, whether it installs and runs in a clean 
install directory.
   Use `make PREFIX=/tmp/chicken` to install into non-existent directory 
/tmp/chicken.
   Also please include the output from the make.

Jim

On Jul 16, 2013, at 12:06 AM, Jim Ursetto <address@hidden> wrote:

> Hi,
> 
> This patch turned out to break the OS X build.  It removes the need to set 
> SONAME_VERSION when calling the install-bin target, and therefore implicitly 
> sets SONAME_VERSION to .$BINARYVERSION.  Unfortunately, some platforms such 
> as OS X didn't use an SONAME_VERSION at all.  It worked before because the 
> SONAME_VERSION setting code was never reached on OS X, being conditional upon 
> NEEDS_RELINKING, whatever that does.  Now, however, the version number is 
> always set.
> 
> The upshot is it installs libchicken.dylib.7 (which is probably an 
> illegal/nonstandard name), but does *not* make a symlink from 
> libchicken.dylib to it, as USES_SONAME is not set.  It is possible to work 
> around this problem with a manual symlink.
> 
> My thought was to make the install of the versioned library conditional upon 
> USES_SONAME as well, so OS X would go back to plain libchicken.dylib.  
> However, for whatever reason, Solaris sets NEEDS_RELINKING *without* 
> USES_SONAME, which would probably break with this solution.
> 
> Therefore I'm not sure yet how to fix this correctly.  I think the logic is 
> rickety and patching it just changed the failure case around.
> 
> The ticket for this issue is http://bugs.call-cc.org/ticket/1022
> 
> Jim
> 
> On Feb 11, 2013, at 10:20 AM, Mario Domenech Goulart <address@hidden> wrote:
> 
>> Hi,
>> 
>> On Sun, 10 Feb 2013 19:29:18 +0100 (CET) Felix <address@hidden> wrote:
>> 
>>>> I'm not sure about the right fix for this issue.  Can't we just get rid
>>>> of SONAME_VERSION and use BYNARYVERSION instead?
>>> 
>>> Sounds right to me.
>> 
>> Attached is a patch that does that.  I've tested it for the mips
>> cross-compilation case using "libs install-dev" as target and a regular
>> installation (no cross-compilation) on linux/x86.  Both seem to work as
>> expected.
>> 
>> 
>>>> Meanwhile, how about changing the manual (Cross development chapter) to
>>>> instruct users to use the "install" target instead of "libs
>>>> install-dev".  It'll probably install unnecessary things, but won't
>>>> break anything, as far as I can see.  With the current instructions, the
>>>> target installation ends up with a libchicken that is a dangling link.
>>> 
>>> Good point. Would you want to do this? Otherwise, create a ticket and
>>> assign it to me, please.
>> 
>> I've updated the wiki docs to suggest "install" instead of "libs
>> install-dev" (and the expected generated tree).
>> 
>> Notice that this wiki change doesn't need to be merged into git's manual
>> if we fix the build system (I know it'll be hard to remember, but I just
>> thought it should be mentioned anyway).  It's just a workaround to match
>> the current chicken's build system behavior.
>> 
>> Best wishes.
>> Mario
>> -- 
>> http://parenteses.org/mario
>> <0001-Drop-SONAME_VERSION-use-.-BINARYVERSION-instead.patch>_______________________________________________
>> Chicken-hackers mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/chicken-hackers
>