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 mario.goul...@gmail.com [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
Hi,
On Sun, 10 Feb 2013 19:29:18 +0100 (CET) Felix
fe...@call-with-current-continuation.org 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
Hi,
On Sat, 2 Feb 2013 18:08:34 +0100 Christian Kellermann ck...@pestilenz.org
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.
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. It'll
On Sun, 10 Feb 2013 19:29:18 +0100 (CET) Felix
fe...@call-with-current-continuation.org 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.
* felix winkelmann fe...@call-with-current-continuation.org [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
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 need this
* felix winkelmann fe...@call-with-current-continuation.org [130203 01:03]:
From: Christian Kellermann ck...@pestilenz.org
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
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
From: Christian Kellermann ck...@pestilenz.org
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 libs target. It
11 matches
Mail list logo
