Two of them are expected failures. For the third, try the patch below.
If it works, then no reason to post the testsuite.log again.
I will then apply your patch after we have sorted out the git mess.
Indeed, no more failure. I still have 2 problems with another lib
1) One is just a
Behdad Esfahbod wrote:
On Fri, 2008-04-18 at 02:32 +0300, Roumen Petrov wrote:
Behdad Esfahbod wrote:
[SNIP]
But if user run directly an application installed in non-default
location the user is responsible to set environment.
I'm not talking about application installed in non-default
* Roumen Petrov wrote on Fri, Apr 18, 2008 at 08:32:23PM CEST:
About no way to fix this problem with autotools. Why ?
As example libxml can run binaries from build dir. In one of the tests
is created specific xml catalog and application is run with this catalog
instead with system.
OK,
On Fri, 2008-04-18 at 21:53 +0300, Roumen Petrov wrote:
In some cases application depend from other services.
In this case a specific to project wrapper script has to run
services,
to check if service is run, to run project application and when
application finish to stop service. The test
On Fri, 2008-04-18 at 21:32 +0300, Roumen Petrov wrote:
About no way to fix this problem with autotools. Why ?
As example libxml can run binaries from build dir. In one of the
tests
is created specific xml catalog and application is run with this
catalog
instead with system.
Stop
* Roumen Petrov wrote on Fri, Apr 18, 2008 at 08:53:12PM CEST:
In some cases application depend from other services.
In this case a specific to project wrapper script has to run services,
to check if service is run, to run project application and when
application finish to stop service.
On Fri, 18 Apr 2008, Roumen Petrov wrote:
Because I think that modules/application/packages/etc should do their best
work. I don't think that a particular package hast o support partially or to
implement very basic functionality. The est example is microsoft software
where application is
* Bob Friesenhahn wrote on Fri, Apr 18, 2008 at 09:15:55PM CEST:
The only substantial change is for static builds which currently
don't have a wrapper.
Yes.
The static build is a more significant concern since static builds are
often used for debugging purposes and if we hide the static
Behdad Esfahbod wrote:
On Fri, 2008-04-18 at 21:53 +0300, Roumen Petrov wrote:
In some cases application depend from other services.
In this case a specific to project wrapper script has to run
services,
to check if service is run, to run project application and when
application finish to
On Fri, 18 Apr 2008, Ralf Wildenhues wrote:
We need to make sure
that it is both possible to obtain the necessary run-time environment,
and to run the debugger on the correct binary. Proposals for the
cleanest way to do that are appreciated.
Well, did this cease to work (except for the bug
Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Fri, Apr 18, 2008 at 09:15:55PM CEST:
The only substantial change is for static builds which currently
don't have a wrapper.
Yes.
The static build is a more significant concern since static builds are
often used for debugging purposes and if
On Fri, 2008-04-18 at 22:27 +0300, Roumen Petrov wrote:
I perfectly know that user
cannot go in build-dir and just to run secure shell daemon/client.
And if you are happy with that, good for you. In GNOME though, we want
our users to be able to run uninstalled programs. If this feature is
Behdad Esfahbod wrote:
On Fri, 2008-04-18 at 22:27 +0300, Roumen Petrov wrote:
I perfectly know that user
cannot go in build-dir and just to run secure shell daemon/client.
And if you are happy with that, good for you.
:)
In GNOME
Ohh no
though, we want
our users to be able to run
* Bob Friesenhahn wrote on Sat, Apr 12, 2008 at 05:51:28PM CEST:
The patch looks ok to me. We shall see about the actual performance
improvement.
Thanks, applied.
Cheers,
Ralf
2008-04-12 Ralf Wildenhues [EMAIL PROTECTED]
* libltdl/config/ltmain.m4sh (func_mode_compile): Avoid
14 matches
Mail list logo
