On Mon, Jul 07, 2003 at 08:42:14PM -0400, Charles Wilson wrote:
> Alexandre Duret-Lutz wrote:
>
> >
> > R> For several _YEARS_, packagers for software were very troubled because
> > R> of not-completely-working staging install. I really hope this issue can
> > R> be sorted out, once and for al
On 2003-07-07(Mon) 19:49:08 -0500, Bob Friesenhahn wrote:
> > Does this mean that things are more likely to be corrected if test cases
> > are added?
>
> Yes, of course. Without minimal tests which exercize the necessary
> operations, the libtool maintainer is forced to assume that his
> changes
Bernd Jendrissek wrote:
I get this:
/tmp/destdir-relinklib-demo-1.0.1: LD_LIBRARY_PATH=/tmp/relinkdemo/usr/lib ldd /tmp/relinkdemo/usr/lib/libtwo.so.1.1.1
libone.so.2 => /tmp/relinkdemo/usr/lib/libone.so.2 (0x40002000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40012000)
libc
On Tue, 8 Jul 2003, Abel Cheung wrote:
> On 2003-07-07(Mon) 23:03:24 +0200, Alexandre Duret-Lutz wrote:
> > R> For several _YEARS_, packagers for software were very troubled because
> > R> of not-completely-working staging install. I really hope this issue can
> > R> be sorted out, once and for
Alexandre Duret-Lutz wrote:
R> For several _YEARS_, packagers for software were very troubled because
R> of not-completely-working staging install. I really hope this issue can
R> be sorted out, once and for all.
One way to address the "once for all" part would be to write a
test case.
I don't
On 2003-07-07(Mon) 23:03:24 +0200, Alexandre Duret-Lutz wrote:
> R> For several _YEARS_, packagers for software were very troubled because
> R> of not-completely-working staging install. I really hope this issue can
> R> be sorted out, once and for all.
>
> One way to address the "once for all"
>>> "R" == R I P Deaddog <[EMAIL PROTECTED]> writes:
[...]
R> For several _YEARS_, packagers for software were very troubled because
R> of not-completely-working staging install. I really hope this issue can
R> be sorted out, once and for all.
One way to address the "once for all" part would
On 2003-07-06(Sun) 11:08:58 -0500, Bob Friesenhahn wrote:
> There is a "catch-22" with this approach in that adding
> -L$inst_prefix_dir to the front of the linker search path may cause
> the wrong dependency libraries to be used, which is just as bad as
> picking up the wrong target library. The
On 2003-07-06(Sun) 11:08:58 -0500, Bob Friesenhahn wrote:
> There is a "catch-22" with this approach in that adding
> -L$inst_prefix_dir to the front of the linker search path may cause
> the wrong dependency libraries to be used, which is just as bad as
> picking up the wrong target library. The
On Sat, Jul 05, 2003 at 02:09:40PM -0400, Charles Wilson wrote:
> Bernd Jendrissek wrote:
> > I realise this may be an FAQ candidate, but I haven't gotten any joy out
> > of google or the mail.gnu.org archives.
> >
> > My problem:
> >
> > I have, say, guile 1.4 installed, with libguile.so.9 in /u
On Sun, 6 Jul 2003, Abel Cheung wrote:
> On 2003-07-05(Sat) 14:09:40 -0400, Charles Wilson wrote:
> > Other than identifying the problem, I don't really know how to correct
> > the remaining issue. But in this message
> >
> > http://mail.gnu.org/archive/html/libtool/2003-05/msg00022.html
> >
> >
On 2003-07-05(Sat) 14:09:40 -0400, Charles Wilson wrote:
> Other than identifying the problem, I don't really know how to correct
> the remaining issue. But in this message
>
> http://mail.gnu.org/archive/html/libtool/2003-05/msg00022.html
>
> I posted a test case that demonstrates the issue; i
Bernd Jendrissek wrote:
I realise this may be an FAQ candidate, but I haven't gotten any joy out
of google or the mail.gnu.org archives.
My problem:
I have, say, guile 1.4 installed, with libguile.so.9 in /usr/lib. Now
I've tried to build guile 1.6.4 with a DESTDIR=foo install, but then
things ge
13 matches
Mail list logo
