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
* Mario Domenech Goulart [130211 17:36]:
> 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.
Thank you again, I have teste
Hi,
On Sun, 10 Feb 2013 19:29:18 +0100 (CET) Felix
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 ca
Hi!
* Mario Domenech Goulart [130211 17:36]:
> Hi,
>
> On Sun, 10 Feb 2013 19:29:18 +0100 (CET) Felix
> 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 pa
>> Good point. Would you want to do this? Otherwise, create a ticket and
>> assign it to me, please.
>
> Sure. I can do that (I mean modify the docs, not create the ticket).
Thanks a lot.
cheers,
felix
___
Chicken-hackers mailing list
Chicken-hacker
On Sun, 10 Feb 2013 19:29:18 +0100 (CET) Felix
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.
Alright. I'm gonna prepare a patch for that.
>> Meanwhile, how about changing the manua
> 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.
>
> Meanwhile, how about changing the manual (Cross development chapter) to
> instruct users to use the "install" target instead of "libs
> install-dev
Hi,
On Sat, 2 Feb 2013 18:08:34 +0100 Christian Kellermann
wrote:
> As I went through the instruction for cross-compilation in the
> manual I read about the "libs" target. It seems to me that it creates
> the so lib and its symbolic link the opposite way as install-libs
> does. Which results in
* felix winkelmann [130204 21:29]:
> >> I'm not sure about this. I know that the current behaviour is not
> >> fully correct, but I repeatedly had problems the other way round, I
> >> think mostly in the situation when I ran freshly built binaries in the
> >> current build-directory, without insta
>> I'm not sure about this. I know that the current behaviour is not
>> fully correct, but I repeatedly had problems the other way round, I
>> think mostly in the situation when I ran freshly built binaries in the
>> current build-directory, without installation (this may sound
>> peculiar, but I n
* felix winkelmann [130203 01:03]:
> From: Christian Kellermann
> Subject: [Chicken-hackers] [PATCH] Apply the same naming scheme for .so libs
> in "libs" target
> Date: Sat, 2 Feb 2013 18:08:34 +0100
>
> > Hi all,
> >
> > As I went through t
From: Christian Kellermann
Subject: [Chicken-hackers] [PATCH] Apply the same naming scheme for .so libs in
"libs" target
Date: Sat, 2 Feb 2013 18:08:34 +0100
> Hi all,
>
> As I went through the instruction for cross-compilation in the
> manual I read about the "l
Hi all,
As I went through the instruction for cross-compilation in the
manual I read about the "libs" target. It seems to me that it creates
the so lib and its symbolic link the opposite way as install-libs
does. Which results in a broken link when you call install-libs
later on. I also think that
13 matches
Mail list logo
