GNU bug report logs - #37499
Wrong location of deps directory when using AC_SUBST

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37499 in the body.
You can then email your comments to 37499 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Fabrizio Bertocci <fabriziobertocci <at> gmail.com>
To: submit <at> debbugs.gnu.org
Subject: Wrong location of deps directory when using AC_SUBST
Date: Tue, 24 Sep 2019 08:55:50 -0400

[Message part 1 (text/plain, inline)]

Package: automake
Version: 1.15.1

I have noticed a strange/wrong behavior when using AC_SUBST to pass a path
to Makefile.am to be used to include additional source files.
In my configure.ac I allow definition of a MYLIB_PATH variable through
--with-mylib=...
The path identify a directory where I have additional common sources that I
want to include in my final build (I know I should build that as a separate
lib, but this is not the point).

This is the configure.ac:
-----------------------------------------
AC_INIT(testApp, 1.0, fabriziobertocci <at> gmail.com)
AC_CONFIG_SRCDIR([src/main.c])
AM_INIT_AUTOMAKE([subdir-objects])
AC_PROG_CC
AC_CONFIG_MACRO_DIRS([m4])

AC_ARG_WITH(mylib,
[  --with-mylib=PATH     Sets PATH where my lib is checked out (../mylib) ],
[
        MYLIB_PATH="${withval}"
        AC_MSG_RESULT(Using MYLib library from ${withval})
],[
        MYLIB_PATH="../mylib"
])

dnl Verify the common lib dir is found
AC_CHECK_FILE("$MYLIB_PATH/mylib.h",
      [     AC_MSG_RESULT(Successfully found mylib.h under "${MYLIB_PATH}")
      ],[   AC_MSG_ERROR(Cannot find MyLibrary. Use --with-mylib parameter
to specify where lib is checked out)
] )

dnl Use relative path:
dnl MYLIB_PATH=`realpath --relative-to src "${MYLIB_PATH}"`

dnl Use absolute path of lib
MYLIB_PATH=`readlink -f ${MYLIB_PATH}`

AC_MSG_RESULT(Using MyLibrary relative to src: ${MYLIB_PATH})
AC_SUBST(MYLIB_PATH)
AC_OUTPUT(Makefile src/Makefile)
-----------------------------------
Then in my src/Makefile.am, I add to my sources, the files from @MYLI_PATH@:
-----------------------------------
bin_PROGRAMS = testApp
testApp_SOURCES = main.c @MYLIB_PATH@/mylib_log.c
testApp_CFLAGS = -I <at> MYLIB_PATH@/lib
------------------------------------

Problem:
If I define MYLIB_PATH as RELATIVE path to the 'src' directory (inside my
project), everything works fine (in the configure.ac, use the realpath
utility to convert any MYLIB_PATH to relative to the 'src' dir).
Unfortunately if MYLIB_PATH is an ABSOLUTE PATH (as in the example above),
it doesn't work.
After running configure, the .deps directory is created under src like if
the MYLIB_PATH is stripped out of the first '/':
So for example if I have my project under:
/home/fabrizio/test/autotool-issue/lib
/home/fabrizio/test/autotool-issue/proj   <- this is where is configure.ac
/home/fabrizio/test/autotool-issue/proj/src   <- This is where are the
sources
After running configure, I get the .deps directory created here:
/home/fabrizio/test/autotool-issue/proj/src/home/fabrizio/test/autotool-issue/lib/.deps/testApp-mylib_log.Po

The workaround is to use always relative path.
I have a full reproducible project I could attach. Just let me know.
I have used this pattern for more than 10 years, but I don't remember ever
seeing this issue (although I attempted to use absolute paths only now).
Tested with newer systems like Linux Mint 19.2 as well as a bit older
systems like CentOS 7. Same problem on both.

Regards,
Fabrizio Bertocci

[Message part 2 (text/html, inline)]

Message #8 received at 37499 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: fabriziobertocci <at> gmail.com
Cc: 37499 <at> debbugs.gnu.org
Subject: Re: bug#37499: Wrong location of deps directory when using AC_SUBST
Date: Mon, 23 Nov 2020 19:06:52 -0700

Hi Fabrizio - sorry for the absurdly delayed reply.
Also sorry, but I don't exactly understand.

    dnl Use absolute path of lib
    MYLIB_PATH=`readlink -f ${MYLIB_PATH}`
    ...
    testApp_SOURCES = main.c @MYLIB_PATH@/mylib_log.c
    testApp_CFLAGS = -I <at> MYLIB_PATH@/lib
    ...
    After running configure, I get the .deps directory created here:
    /home/fabrizio/test/autotool-issue/proj/src/home/fabrizio/test/autotool-issue/lib/.deps/testApp-mylib_log.Po

Are you saying an older version used to not insert the full directory
path when making the .deps? So that it ended up being (I guess):
/home/fabrizio/test/autotool-issue/proj/src/lib/.deps/testApp-mylib_log.Po
Do you know what version worked?

If it worked with an older version and doesn't work now, I could try to
look. Otherwise it is hard to guess what could have changed. My first
reaction is that automake is just using the path it's given; I wouldn't
expect it to the relativization itself? I suspect I'm misunderstanding
something.

    I have a full reproducible project I could attach. Just let me know.

For sure a reproducible case would be helpful in understanding. The
smaller the better.

Thanks,
Karl

Message #11 received at 37499 <at> debbugs.gnu.org (full text, mbox):

From: Fabrizio Bertocci <fabriziobertocci <at> gmail.com>
To: Karl Berry <karl <at> freefriends.org>
Cc: 37499 <at> debbugs.gnu.org
Subject: Re: bug#37499: Wrong location of deps directory when using AC_SUBST
Date: Tue, 24 Nov 2020 15:09:15 -0500

[Message part 1 (text/plain, inline)]

Karl,
It took me a while to remember what this issue was about... but I managed
to get to my old reproducer.

Ok, let me do one step back. The root problem is how do I ensure that paths
passed through ./configure command line are valid when building source code
under 'src' (for example).

Look at the two attached .tar.gz. and un-tar the one called
'autotool-bug-rel.tar.gz'.
In this project I have:
/proj             <- Here is where is the configure script
/proj/src       <- Here is the source code
/lib               <- This is another location of some lib I want to be
able to define through ./configure

Enter the `proj/src` and generate the configure script (./bootstrap.sh or
just use autoreconf).

The configure script accepts a parameter `--with-mylib=<dir>` where the
library code is located.
Launch it with:
./configure --with-mylib=../lib

Note that now ../lib is a valid path only for the /proj directory, when
building inside the '/proj/src' directory, that directory is no longer
valid (that's why it needs to be converted somehow to something that makes
sense for the `src` directory).

I have two options at this point:
1. Make this library path relative to the 'src' directory
2. Convert the provided path to absolute

These two approaches although very similar lead to an error when using
absolute paths. Note the issue is not in the conversion between
relative/absolute paths.
If I don't change the path provided through the --with-mylib parameter, and
I enter an absolute path, I'm getting the same problem.

Let's go back to my test example, this version of the configure.ac follows
the first approach (converts all the values to paths relative to the src
directory):
MYLIB_PATH=`realpath --relative-to src "${MYLIB_PATH}"`

Do a build. After the building completes, you end up with two .deps
directories, one under 'test/proj/src' and one under the 'test/lib'
directory:
test/proj/src/.deps   <- .Po files for the files under 'src'
test/lib/.deps           <- .Po files for the files under 'lib'

So far so good.
Cleanup everything (do an rm -Rf of the autotool-bug directory entirely)
and un-tar the other file (autotool-bug-abs.tar.gz).
This example is exactly like the other one, but the configure.ac converts
the library path to absolute:
MYLIB_PATH=`readlink -f ${MYLIB_PATH}`

Again, generate the configure script and run: configure --with-mylib=../lib

Now when you build you are going to get an error because it is looking for
the .Po file in the (right/wrong?) directory.
The .Po file is trying to locate (expected to be under `/lib/.deps`) is in
a wrong directory: proj/src/home/fabrizio/test/lib/.deps

See the problem? It seems when using absolute paths, the .Po file is
created in the wrong directory and the build fails.
Take a look at the content of the src/home/...../.deps. There is a .Po file
containing only a "# dummy" line.

Tested with autoconf 2.69.

Regards,
Fabrizio




On Mon, Nov 23, 2020 at 9:06 PM Karl Berry <karl <at> freefriends.org> wrote:

> Hi Fabrizio - sorry for the absurdly delayed reply.
> Also sorry, but I don't exactly understand.
>
>     dnl Use absolute path of lib
>     MYLIB_PATH=`readlink -f ${MYLIB_PATH}`
>     ...
>     testApp_SOURCES = main.c @MYLIB_PATH@/mylib_log.c
>     testApp_CFLAGS = -I <at> MYLIB_PATH@/lib
>     ...
>     After running configure, I get the .deps directory created here:
>
> /home/fabrizio/test/autotool-issue/proj/src/home/fabrizio/test/autotool-issue/lib/.deps/testApp-mylib_log.Po
>
> Are you saying an older version used to not insert the full directory
> path when making the .deps? So that it ended up being (I guess):
> /home/fabrizio/test/autotool-issue/proj/src/lib/.deps/testApp-mylib_log.Po
> Do you know what version worked?
>
> If it worked with an older version and doesn't work now, I could try to
> look. Otherwise it is hard to guess what could have changed. My first
> reaction is that automake is just using the path it's given; I wouldn't
> expect it to the relativization itself? I suspect I'm misunderstanding
> something.
>
>     I have a full reproducible project I could attach. Just let me know.
>
> For sure a reproducible case would be helpful in understanding. The
> smaller the better.
>
> Thanks,
> Karl
>

[Message part 2 (text/html, inline)]

[autotool-bug-abs.tar.gz (application/gzip, attachment)]

[autotool-bug-rel.tar.gz (application/gzip, attachment)]

Message #14 received at 37499 <at> debbugs.gnu.org (full text, mbox):

From: Hans-Bernhard Bröker <HBBroeker <at> t-online.de>
To: Fabrizio Bertocci <fabriziobertocci <at> gmail.com>,
 Karl Berry <karl <at> freefriends.org>
Cc: 37499 <at> debbugs.gnu.org
Subject: Re: bug#37499: Wrong location of deps directory when using AC_SUBST
Date: Tue, 24 Nov 2020 23:24:47 +0100

Am 24.11.2020 um 21:09 schrieb Fabrizio Bertocci:
> Karl,
> It took me a while to remember what this issue was about... but I 
> managed to get to my old reproducer.
> 
> Ok, let me do one step back. The root problem is how do I ensure that 
> paths passed through ./configure command line are valid when building 
> source code under 'src' (for example).
> 
> Look at the two attached .tar.gz. and un-tar the one called 
> 'autotool-bug-rel.tar.gz'.
> In this project I have:
> /proj             <- Here is where is the configure script
> /proj/src       <- Here is the source code
> /lib               <- This is another location of some lib I want to be 
> able to define through ./configure
> 
> Enter the `proj/src` and generate the configure script (./bootstrap.sh 
> or just use autoreconf).

How is that possible, given the configure script is supposed to be in 
'proj', not 'proj/src'?

> Launch it with:
> ./configure --with-mylib=../lib

Similar problem here.  If you are where you say, in proj/src, that would 
have to be ../../lib.

So let's assume you meant to say that CWD is 'proj'.

Well, I don't think it was ever meant to be possible that sources lie 
outside the subtree configure itself is in.

IOW, $(top_srcdir) is, by definition, the location of the ./configure 
script, and it actually has to be what it says in the name: the _top_ 
source directory for stuff built by that configure and its resulting 
Makefile.

The source tree should thus be

proj         configury here
proj/src     sources here
proj/lib     other sources here

This may actually be related to my ancient bug entry #20699.

Message #17 received at 37499 <at> debbugs.gnu.org (full text, mbox):

From: Fabrizio Bertocci <fabriziobertocci <at> gmail.com>
To: Hans-Bernhard Bröker <HBBroeker <at> t-online.de>
Cc: 37499 <at> debbugs.gnu.org, Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#37499: Wrong location of deps directory when using AC_SUBST
Date: Tue, 24 Nov 2020 17:53:16 -0500

[Message part 1 (text/plain, inline)]

Hans,
Yes, the project is very uncommon, and I agree the lib should be inside the
project directory structure, but I had this issue a long long time ago when
working on an embedded system that shared some libraries between host and
target machine.
I don't know if it's even a bug or just an unsupported condition that leads
to unexpected results.
Regards,
Fabrizio


On Tue, Nov 24, 2020 at 5:24 PM Hans-Bernhard Bröker <HBBroeker <at> t-online.de>
wrote:

> Am 24.11.2020 um 21:09 schrieb Fabrizio Bertocci:
> > Karl,
> > It took me a while to remember what this issue was about... but I
> > managed to get to my old reproducer.
> >
> > Ok, let me do one step back. The root problem is how do I ensure that
> > paths passed through ./configure command line are valid when building
> > source code under 'src' (for example).
> >
> > Look at the two attached .tar.gz. and un-tar the one called
> > 'autotool-bug-rel.tar.gz'.
> > In this project I have:
> > /proj             <- Here is where is the configure script
> > /proj/src       <- Here is the source code
> > /lib               <- This is another location of some lib I want to be
> > able to define through ./configure
> >
> > Enter the `proj/src` and generate the configure script (./bootstrap.sh
> > or just use autoreconf).
>
> How is that possible, given the configure script is supposed to be in
> 'proj', not 'proj/src'?
>
> > Launch it with:
> > ./configure --with-mylib=../lib
>
> Similar problem here.  If you are where you say, in proj/src, that would
> have to be ../../lib.
>
> So let's assume you meant to say that CWD is 'proj'.
>
> Well, I don't think it was ever meant to be possible that sources lie
> outside the subtree configure itself is in.
>
> IOW, $(top_srcdir) is, by definition, the location of the ./configure
> script, and it actually has to be what it says in the name: the _top_
> source directory for stuff built by that configure and its resulting
> Makefile.
>
> The source tree should thus be
>
> proj         configury here
> proj/src     sources here
> proj/lib     other sources here
>
> This may actually be related to my ancient bug entry #20699.
>

[Message part 2 (text/html, inline)]

Message #20 received at 37499 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: fabriziobertocci <at> gmail.com
Cc: 37499 <at> debbugs.gnu.org
Subject: Re: bug#37499: Wrong location of deps directory when using AC_SUBST
Date: Sat, 28 Nov 2020 19:46:23 -0700

Hi Fabrizio - unfortunately, your examples work for me, in that I can
run, in the proj/ directory, either
./configure --with-mylib=../lib
or
./configure --with-mylib=/abs/path/to/autotool-bug/lib

and then make, in either the proj/ directory or the proj/src
subdirectory, and it all completes successfully.
All this with both your tarballs. So I remain unclear as to what you're
doing. Sorry.

Since configure is run in the proj/ directory, not proj/src, it seems
evident that any method, absolute or relative, which specifies mylib to
be the ../../lib directory cannot work, because that directory will not
exist relative to proj/.

Can you tell me exactly what commands you are running, starting with
tar xf <tarfile> (and which <tarfile> to use), to see the problem?
Just one sequence to reproduce the problem is enough.

    a wrong directory: proj/src/home/fabrizio/test/lib/.deps

In any event, this blind concatenation of paths surely looks
wrong. Maybe if the path (whatever it is) is absolute, the concatenation
should be avoided.

Unfortunately, I cannot discern where the computations are happening,
whether it's somewhere in the depcomp script or the Makefile that's
calling it.

In addition, I agree with Hans-Bernhard that using a directory outside
of top_srcdir is not exactly supported, although evidently it works in
some cases. Even if it cannot be handled properly, perhaps a real error
message could be given, or at least the deficiency documented.

Thanks,
Karl

Message #23 received at 37499 <at> debbugs.gnu.org (full text, mbox):

From: Fabrizio Bertocci <fabriziobertocci <at> gmail.com>
To: Karl Berry <karl <at> freefriends.org>
Cc: 37499 <at> debbugs.gnu.org
Subject: Re: bug#37499: Wrong location of deps directory when using AC_SUBST
Date: Mon, 7 Dec 2020 07:44:02 -0500

[Message part 1 (text/plain, inline)]

Karl,
Sorry for the late reply.
Here are the sequence of the commands that show the issue described:


*Test use of relative path to identify external lib:*

$ tar xfz autotool-bug-rel.tar.gz
$ cd autotool-bug/proj
$ ./bootstrap.sh
$ ./configure --with-mylib=../lib
$ make
$ ls -la src/.deps              # Note the testApp-main.Po
$ ls -la ../lib                 # Note the .deps and .dirstamp
$ ls -la ../lib/.deps           # Note the testApp-mylib_log.Po and
.dirstamp
$ cd ../..
$ mv autotool-bug autotool-bug-rel  # Move it out of the way
------------------------------


*Test use of absolute path to identify external lib:*

$ tar xfz autotool-bug-abs.tar.gz
$ cd autotool-bug/proj
$ ./bootstrap.sh
$ ./configure --with-mylib=../lib
$ make
Making all in src
make[1]: Entering directory '/home/fabrizio/temp/autotool-bug/proj/src'
Makefile:353:
/home/fabrizio/temp/autotool-bug/lib/.deps/testApp-mylib_log.Po: No such
file or directory
make[1]: *** No rule to make target
'/home/fabrizio/temp/autotool-bug/lib/.deps/testApp-mylib_log.Po'.  Stop.
make[1]: Leaving directory '/home/fabrizio/temp/autotool-bug/proj/src'
Makefile:331: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

$ ls -la src
total 72
drwxr-xr-x 4 fabrizio fabrizio  4096 Dec  7 07:33 .
drwxr-xr-x 4 fabrizio fabrizio  4096 Dec  7 07:33 ..
drwxr-xr-x 2 fabrizio fabrizio  4096 Dec  7 07:33 .deps
drwxr-xr-x 3 fabrizio fabrizio  4096 Dec  7 07:33 home               ######
???????
-rw-r--r-- 1 fabrizio fabrizio    83 Sep 24  2019 main.c
-rw-r--r-- 1 fabrizio fabrizio 22554 Dec  7 07:33 Makefile
-rw-r--r-- 1 fabrizio fabrizio   106 Nov 24 14:01 Makefile.am
-rw-r--r-- 1 fabrizio fabrizio 22001 Dec  7 07:33 Makefile.in

--------------------------------


*Differences between the two use case:*

$ diff configure.ac ../../autotool-bug-rel/proj/configure.ac
28c28
< dnl MYLIB_PATH=`realpath --relative-to src "${MYLIB_PATH}"`
---
> MYLIB_PATH=`realpath --relative-to src "${MYLIB_PATH}"`
31c31
< MYLIB_PATH=`readlink -f ${MYLIB_PATH}`
---
> dnl MYLIB_PATH=`readlink -f ${MYLIB_PATH}`


In the 'relative path' case, MYLIB_PATH uses realpath to calculate ../lib
relative to the 'src' directory.
In the 'absolute path' case, MYLIB_PATH contains the full absolute path of
the ../lib.
Note that in the 'absolute path' case, there is a new 'home' directory
under 'src'  containing the full tree to the .Po file from the library.

Just try to run those commands and unless is something simple to address,
please close the ticket and let's move on.
I understand that this situation is not really a representative use case
and is not supported.

Regards,
Fabrizio




On Sat, Nov 28, 2020 at 9:46 PM Karl Berry <karl <at> freefriends.org> wrote:

> Hi Fabrizio - unfortunately, your examples work for me, in that I can
> run, in the proj/ directory, either
> ./configure --with-mylib=../lib
> or
> ./configure --with-mylib=/abs/path/to/autotool-bug/lib
>
> and then make, in either the proj/ directory or the proj/src
> subdirectory, and it all completes successfully.
> All this with both your tarballs. So I remain unclear as to what you're
> doing. Sorry.
>
> Since configure is run in the proj/ directory, not proj/src, it seems
> evident that any method, absolute or relative, which specifies mylib to
> be the ../../lib directory cannot work, because that directory will not
> exist relative to proj/.
>
> Can you tell me exactly what commands you are running, starting with
> tar xf <tarfile> (and which <tarfile> to use), to see the problem?
> Just one sequence to reproduce the problem is enough.
>
>     a wrong directory: proj/src/home/fabrizio/test/lib/.deps
>
> In any event, this blind concatenation of paths surely looks
> wrong. Maybe if the path (whatever it is) is absolute, the concatenation
> should be avoided.
>
> Unfortunately, I cannot discern where the computations are happening,
> whether it's somewhere in the depcomp script or the Makefile that's
> calling it.
>
> In addition, I agree with Hans-Bernhard that using a directory outside
> of top_srcdir is not exactly supported, although evidently it works in
> some cases. Even if it cannot be handled properly, perhaps a real error
> message could be given, or at least the deficiency documented.
>
> Thanks,
> Karl
>

[Message part 2 (text/html, inline)]

Message #26 received at 37499 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: fabriziobertocci <at> gmail.com
Cc: 37499 <at> debbugs.gnu.org
Subject: Re: bug#37499: Wrong location of deps directory when using AC_SUBST
Date: Tue, 8 Dec 2020 19:20:03 -0700

Hi Fabrizio,

    $ tar xfz autotool-bug-abs.tar.gz
    $ cd autotool-bug/proj
    $ ./bootstrap.sh
    $ ./configure --with-mylib=../lib
    $ make

Thanks for the careful recipe. Unfortunately, it still works for me.
readlink -f does return the full path, and I see the full path embedded
in the Makefiles in various places, but not the crucial line:

Makefile:353:/home/fabrizio/temp/autotool-bug/lib/.deps/testApp-mylib_log.Po: No such

Line 353 of my src/Makefile is simply
DEPDIR = .deps

which, I guess, explains why it is not failing for me. But I find myself
unable to guess why you are getting a full path there. Looking at the
way $(DEPDIR) is used, it seems expected that it is simply .deps (minus
the leading . on Windows I guess).

I wonder ... are you using an original automake 1.16.x from ftp.gnu.org?
Or are you maybe using a distro version of automake? That could explain
the different behavior (i.e., the distro people introduced some subtle
problem). Otherwise, I'm at a loss.

    Just try to run those commands and unless is something simple to
    address, please close the ticket and let's move on.

It doesn't look simple, so closing as instructed :).

All the best,
Karl

Message #34 received at 37499 <at> debbugs.gnu.org (full text, mbox):

From: Fabrizio Bertocci <fabriziobertocci <at> gmail.com>
To: Karl Berry <karl <at> freefriends.org>
Cc: 37499 <at> debbugs.gnu.org
Subject: Re: bug#37499: Wrong location of deps directory when using AC_SUBST
Date: Tue, 8 Dec 2020 21:30:40 -0500

[Message part 1 (text/plain, inline)]

Karl,
Thank you for all the time spent on this issue.
Yeah actually I am using automake 1.15.1 that comes with Linux Mint 19.2
distro:
automake/bionic,bionic,now 1:1.15.1-3ubuntu2 all [installed]

I saw you closed the ticket. good. Thanks again!
Regards,
Fabrizio



On Tue, Dec 8, 2020 at 9:20 PM Karl Berry <karl <at> freefriends.org> wrote:

> Hi Fabrizio,
>
>     $ tar xfz autotool-bug-abs.tar.gz
>     $ cd autotool-bug/proj
>     $ ./bootstrap.sh
>     $ ./configure --with-mylib=../lib
>     $ make
>
> Thanks for the careful recipe. Unfortunately, it still works for me.
> readlink -f does return the full path, and I see the full path embedded
> in the Makefiles in various places, but not the crucial line:
>
> Makefile:353:/home/fabrizio/temp/autotool-bug/lib/.deps/testApp-mylib_log.Po:
> No such
>
> Line 353 of my src/Makefile is simply
> DEPDIR = .deps
>
> which, I guess, explains why it is not failing for me. But I find myself
> unable to guess why you are getting a full path there. Looking at the
> way $(DEPDIR) is used, it seems expected that it is simply .deps (minus
> the leading . on Windows I guess).
>
> I wonder ... are you using an original automake 1.16.x from ftp.gnu.org?
> Or are you maybe using a distro version of automake? That could explain
> the different behavior (i.e., the distro people introduced some subtle
> problem). Otherwise, I'm at a loss.
>
>     Just try to run those commands and unless is something simple to
>     address, please close the ticket and let's move on.
>
> It doesn't look simple, so closing as instructed :).
>
> All the best,
> Karl
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.