The README file explains it: run
make check VERBOSE=yes TESTS="tests/demo-shared.test tests/demo-make.test
tests/demo-exec.test"
Also, please run the other half of the tests (the new testsuite) using
make check-local
and post tests/testsuite.log, please. You can run both with "make -k
chec
On Thu, 2008-04-17 at 23:38 +0300, Roumen Petrov wrote:
>
>
> I think that all above is out of libtool scope.
> It's is exceptional project specific (lets skip cross-compilation
> environment) and is subject of project regression test suite.
> The project is responsible to set appropriate test e
On Thu, 17 Apr 2008, Behdad Esfahbod wrote:
If running uninstalled build is not a goal, why bother about
LD_LIBRARY_PATH'ing the uninstalled library path at all?
I feel your pain. As a workaround, for my own software I add a small
script which exports environment variables prior to running e
On Thu, 2008-04-17 at 16:40 -0500, Bob Friesenhahn wrote:
>
> An unfortunate thing is that not all software is configured the same.
> For example, my own software supports independent configuration for
> the location of different types of files. A single top "prefix"
> environment variable wou
* Bob Friesenhahn wrote on Thu, Apr 17, 2008 at 11:40:47PM CEST:
> On Thu, 17 Apr 2008, Behdad Esfahbod wrote:
>>
>> If running uninstalled build is not a goal, why bother about
>> LD_LIBRARY_PATH'ing the uninstalled library path at all?
> It seems to me that the proper place to fix this is at the
On Fri, 2008-04-18 at 00:45 +0300, Roumen Petrov wrote:
> Behdad Esfahbod wrote:
> > On Thu, 2008-04-17 at 23:38 +0300, Roumen Petrov wrote:
> >>
> >> I think that all above is out of libtool scope.
> >> It's is exceptional project specific (lets skip cross-compilation
> >> environment) and is su
* Vincent Torri wrote on Thu, Apr 17, 2008 at 06:31:34PM CEST:
>
>> The README file explains it: run
>> make check VERBOSE=yes TESTS="tests/demo-shared.test tests/demo-make.test
>> tests/demo-exec.test"
>>
>> Also, please run the other half of the tests (the new testsuite) using
>> make check-lo
Behdad Esfahbod wrote:
On Tue, 2006-06-13 at 17:00 -0400, Ralf Wildenhues wrote:
[ this is: http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5319
or http://lists.gnu.org/archive/html/bug-libtool/2006-03/msg00013.html ]
Hi Behdad, everyone,
Hi again,
Sorry for the delay again.
So, yeah,
Behdad Esfahbod wrote:
On Thu, 2008-04-17 at 23:38 +0300, Roumen Petrov wrote:
I think that all above is out of libtool scope.
It's is exceptional project specific (lets skip cross-compilation
environment) and is subject of project regression test suite.
The project is responsible to set appr
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 location.
I'm talking about uninstalled application.
There is no significant differen
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 location.
On Fri, 18 Apr 2008, Roumen Petrov wrote:
And if application don't read environment, next request is libtool wrapper
script to pass arguments to application command line.
The whole idea is libtool overkill.
This statement is a little "over the top". Why are you so vehemently
against exten
Hello Vincent,
* Vincent Torri wrote on Fri, Apr 18, 2008 at 06:51:45AM CEST:
>
>> What about tests/testsuite.log?
Thank you very much for providing this.
>
> # -*- compilation -*-
> 37. am-subdir.at:33: testing ...
[...]
> checking build system type... x86_64-unknow
* Vincent Torri wrote on Fri, Apr 18, 2008 at 07:25:01AM CEST:
>
>> All failing tests fail due to config.sub files which are not up to date.
>> Can you please go ahead and the config.sub file that comes with your
>> installed Automake package to contain your proposed changes? It should
>> be locat
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 warning
15 matches
Mail list logo
