rm -f core cause some troubles

[p***@debian.org]

Hello, I have a problem with one of the projet I am trying to convert to
autoconf/automake.

during the configure process, I got plenty of

rm: cannot remove `core': Is a directory
yes
checking for sys/types.h... rm: cannot remove `core': Is a directory
yes
checking for sys/stat.h... rm: cannot remove `core': Is a directory
yes
checking for stdlib.h... rm: cannot remove `core': Is a directory
yes
checking for string.h... rm: cannot remove `core': Is a directory
yes
checking for memory.h... rm: cannot remove `core': Is a directory
yes
checking for strings.h... rm: cannot remove `core': Is a directory
yes
checking for inttypes.h... rm: cannot remove `core': Is a directory
yes
checking for stdint.h... rm: cannot remove `core': Is a directory
yes
checking for unistd.h... rm: cannot remove `core': Is a directory
yes
checking for dlfcn.h... rm: cannot remove `core': Is a directory
yes

Indeed one directory of the project is named 'core'.

Nevertheless once done with the configuration, 'make' works like a charm
and I obtain the right library.

now to trigger the real effect of this annoying message, the distcheck
target need to be be used

It gives this error

ERROR: files left in build directory after distclean:
./confdefs.h

so it seems to me that it should be allow to have a core directory in a
projetc, this is a valid name. So the logic when removing core files,
would be to check first thta they are real file and not a directory.

what is you opinion, is it an autoconf bug ?

Thanks

Frederic


ii autoconf 2.69-1 all automatic configure script builder

[Paul Eggert]

On 12/08/2012 02:52 AM, ***@debian.org wrote:
> So the logic when removing core files,
> would be to check first thta they are real file and not a directory.

That would slow down 'configure' everywhere.

It might make sense to have an Autoconf option that would
add that behavior as an option, for people who want to have
directories named 'core', and who don't mind the slowdown.

> ERROR: files left in build directory after distclean:
> ./confdefs.h

I don't see how this is related to the problem with 'core'.
It appears to be a separate bug.

For your immediate problem, the simplest thing might be
for you to rename the directory 'core', to 'Core', say.
If that's not possible, you could run 'configure' in
a subdirectory perhaps.

[PICCA Frédéric-Emmanuel]

> That would slow down 'configure' everywhere.

how much ?

> It might make sense to have an Autoconf option that would
> add that behavior as an option, for people who want to have
> directories named 'core', and who don't mind the slowdown.

but if you add an option each time a directory name or other file is not allowed...

> > ERROR: files left in build directory after distclean:
> > ./confdefs.h

> I don't see how this is related to the problem with 'core'.
> It appears to be a separate bug.

what can cause this problem, I find only this line in the configure script

# confdefs.h avoids OS command line length limits that DEFS can exceed.
rm -f -r conftest* confdefs.h

I renamed core -> Core, and this issue just gone.

> For your immediate problem, the simplest thing might be
> for you to rename the directory 'core', to 'Core', say.
> If that's not possible, you could run 'configure' in
> a subdirectory perhaps.

I can not rename it as Core, I need to convince the upstream.
If I run configure in a subdirectory, everythings run fine the first time, then the
core/Makefile is created and the 'rm' problem is triggerred.

cheers,

Frederic

[Paul Eggert]

On 12/08/2012 10:12 AM, PICCA Frédéric-Emmanuel wrote:
>> That would slow down 'configure' everywhere.
>
> how much ?

I don't know. I expect it'd be measurable, though.

> if you add an option each time a directory name or other file is not allowed...

Yes, perhaps it's not a good idea.

> I renamed core -> Core, and this issue just gone.

I don't know why that would be, but perhaps more digging
on your end can find out.

Here's another idea. Define your own 'rm',
which will be a simple shell script that invokes the
real 'rm', except it ignores any 'core' argument. Put
it in your PATH, before the real 'rm'. Then run
configure with that PATH. That should work.

And here's another another idea. When building
'configure', do it like this:

autoconf
sed 's/ core / /g' configure >config.cache
cp config.cache configure

That way, your 'configure' won't try to remove 'core'.
It's a bit of a hack, but it should work.

[PICCA Frédéric-Emmanuel]

> > I renamed core -> Core, and this issue just gone.

> I don't know why that would be, but perhaps more digging
> on your end can find out.

Yes I need to investigate on this

> Here's another idea. Define your own 'rm',
> which will be a simple shell script that invokes the
> real 'rm', except it ignores any 'core' argument. Put
> it in your PATH, before the real 'rm'. Then run
> configure with that PATH. That should work.

yes this could work but it is really a nasty hack...

> And here's another another idea. When building
> 'configure', do it like this:

> autoconf
> sed 's/ core / /g' configure >config.cache
> cp config.cache configure

> That way, your 'configure' won't try to remove 'core'.
> It's a bit of a hack, but it should work.

You mean , I need to maintain a fork of autoconf for this project ;)
To me even if this is slower, the right fix is to avoid removing core if this is a directory.
It will be difficult for me to convince upstream to use autoconf if it needs to change it's
code due to this bug.

cheers,

Frederic

[Paul Eggert]

On 12/08/2012 12:30 PM, PICCA Frédéric-Emmanuel wrote:
> You mean , I need to maintain a fork of autoconf for this project ;)

No, you don't need to change autoconf at all.
You merely edit its output, with 'sed',
before running it. It's easy.

> the right fix is to avoid removing core if this is a directory.

Autoconf-generated 'configure' files already do that.
That's not the issue.

The only issue that has been identified is that
'configure' issues some annoying warnings. There may be
some other issues, but that's all we've found so far.
And the above-mentioned fix resolves that issue.

[Marko Lindqvist]

On 9 December 2012 01:45, Paul Eggert <***@cs.ucla.edu> wrote:
> On 12/08/2012 12:30 PM, PICCA Frédéric-Emmanuel wrote:
>
>> the right fix is to avoid removing core if this is a directory.
>
> Autoconf-generated 'configure' files already do that.
> That's not the issue.
>
> The only issue that has been identified is that
> 'configure' issues some annoying warnings.

So you are saing that "we try to do the wrong thing, but as that
reliably fails, only problem are the error messages from the failure
(to do the wrong thing)"?

As hackish solutions go, I'd consider this particular way of thinking
bad. If reliability of the normal use increases -> failure happens
less reliably when it's hackishly counted on.


- ML

[Paul Eggert]

On 12/08/2012 04:12 PM, Marko Lindqvist wrote:
> So you are saing that

No.

[Jeffrey Walton]

On Sat, Dec 8, 2012 at 7:12 PM, Marko Lindqvist <***@gmail.com> wrote:
> On 9 December 2012 01:45, Paul Eggert <***@cs.ucla.edu> wrote:
>> On 12/08/2012 12:30 PM, PICCA Frédéric-Emmanuel wrote:
>>
>>> the right fix is to avoid removing core if this is a directory.
>>
>> Autoconf-generated 'configure' files already do that.
>> That's not the issue.
>>
>> The only issue that has been identified is that
>> 'configure' issues some annoying warnings.
>
> So you are saing that "we try to do the wrong thing, but as that
> reliably fails, only problem are the error messages from the failure
> (to do the wrong thing)"?
>
> As hackish solutions go, I'd consider this particular way of thinking
> bad. If reliability of the normal use increases -> failure happens
> less reliably when it's hackishly counted on.
Agreed. Before anything, the program has to be correct. Trying to
remove a directory named 'core' does not follow the intention
(informally 'specification') of removing crash dump files.

Special rules (i.e., no 'core' directories) that can only be found by
grepping mailing lists also seems to be less than desirable.

What happens if a user aliases `rm` to `rm -rf`?

Jeff

[Eric Blake]

On 12/08/2012 05:16 PM, Jeffrey Walton wrote:
> Agreed. Before anything, the program has to be correct. Trying to
> remove a directory named 'core' does not follow the intention
> (informally 'specification') of removing crash dump files.

Naming a directory 'core' is dangerous and non-portable, because the
name 'core' is traditionally reserved for core dumps. Similarly, naming
a directory 'aux' is dangerous and non-portable, because the name 'aux'
opens a special device on Windows. Similarly, naming two files with a
case-sensitive clash is unsupported. In short, autoconf sticks with the
philosophy that it is better for you to name your files portably than
for autoconf to bend over backward to special case when those
non-portable names exist on platforms where they happen to work, but
will fall apart on platforms where they do not work.

>
> Special rules (i.e., no 'core' directories) that can only be found by
> grepping mailing lists also seems to be less than desirable.

If you think we need to more fully document that both 'core' and 'aux'
are recommended to be avoided in your project, patches are welcome.

>
> What happens if a user aliases `rm` to `rm -rf`?

Precisely why we are suggesting that you should fix your package to
avoid 'core' as a directory, and not that we fix 'autoconf' to bend over
backwards to support this fringe case.

--
Eric Blake eblake redhat com [phone]
Libvirt virtualization library http://libvirt.org

[Jeffrey Walton]

On Mon, Dec 10, 2012 at 8:36 AM, Eric Blake <***@redhat.com> wrote:
> On 12/08/2012 05:16 PM, Jeffrey Walton wrote:
>> Agreed. Before anything, the program has to be correct. Trying to
>> remove a directory named 'core' does not follow the intention
>> (informally 'specification') of removing crash dump files.
>
> Naming a directory 'core' is dangerous and non-portable, because the
> name 'core' is traditionally reserved for core dumps.
Agreed, but the program is still not correct (assuming the
specification is to remove old core dumps).

Before anything, the program has to be correct. After correctness, the
program should be secure and can be efficient.

Jeff

[Paul Eggert]

On 12/15/2012 12:31 PM, Jeffrey Walton wrote:
> the program is still not correct

Correctness is in the eye of the beholder.
For most people 'configure' behaves as intended,
but it doesn't match your intent. Unfortunately
the discussion we've all had so far suggests that
it's not likely Autoconf will change its behavior
in this area, so I suggest following some of the
advice that I and others already gave to work
around the problem.

[Jeffrey Walton]

On Sat, Dec 15, 2012 at 5:58 PM, Paul Eggert <***@cs.ucla.edu> wrote:
> On 12/15/2012 12:31 PM, Jeffrey Walton wrote:
>>
>> the program is still not correct
>
> Correctness is in the eye of the beholder.
Hmmm....

> For most people 'configure' behaves as intended,
> but it doesn't match your intent.
I'm not sure its my intent. Is the program designed to remove old core
files as part of the autoconf process? Perhaps that's where the
confusion lies.

Perhaps it would be easier (easiest?) to remove that step in the
process? That is, no longer make it a specification of the autoconf
process.

> the discussion we've all had so far suggests that
> it's not likely Autoconf will change its behavior
> in this area, so I suggest following some of the
> advice that I and others already gave to work
> around the problem.
That's fine - I'm used to it (Closed, Won't Fix). It reminds me of
http://linuxhaters.blogspot.com/2008/08/one-bug-report-to-rule-them-all.html
:)

Jeff

[Paul Eggert]

On 12/15/2012 03:08 PM, Jeffrey Walton wrote:
> Is the program designed to remove old core
> files as part of the autoconf process?

No, new cores. 'configure' regularly generates
programs that dump core, as part of its ordinary
working procedure.

[Marko Lindqvist]

On 16 December 2012 02:18, Paul Eggert <***@cs.ucla.edu> wrote:
> On 12/15/2012 03:08 PM, Jeffrey Walton wrote:
>>
>> Is the program designed to remove old core
>> files as part of the autoconf process?
>
>
> No, new cores. 'configure' regularly generates
> programs that dump core, as part of its ordinary
> working procedure.

Does it make sure core is new one it has created. Granted that if one
wants to play with core generated by the program being developet,
(s)he shouldn't be rebuilding program before those investigations, but
potentially core file is valuable.

Is the performance issue in the checking of nature of "core" *every
time* configure has potentially created one to be removed? Could it
just check existing situation in the beginning (is there something
named 'core' already) and to store it to variable for later parts to
use?


- ML

[Paul Eggert]

On 12/15/2012 05:01 PM, Marko Lindqvist wrote:
> Does it make sure core is new one it has created.

No.

> Is the performance issue in the checking of nature of "core" *every
> time* configure has potentially created one to be removed?

Yes.

[NightStrike]

On Sat, Dec 15, 2012 at 2:18 PM, Paul Eggert <***@cs.ucla.edu> wrote:
> On 12/15/2012 03:08 PM, Jeffrey Walton wrote:
>>
>> Is the program designed to remove old core
>> files as part of the autoconf process?
>
>
> No, new cores. 'configure' regularly generates
> programs that dump core, as part of its ordinary
> working procedure.

Why not just use ulimit to not dump core? Or is that a bashism and not a shism?

[Bob Friesenhahn]

On Sat, 15 Dec 2012, NightStrike wrote:

> On Sat, Dec 15, 2012 at 2:18 PM, Paul Eggert <***@cs.ucla.edu> wrote:
>> On 12/15/2012 03:08 PM, Jeffrey Walton wrote:
>>>
>>> Is the program designed to remove old core
>>> files as part of the autoconf process?
>>
>>
>> No, new cores. 'configure' regularly generates
>> programs that dump core, as part of its ordinary
>> working procedure.
>
> Why not just use ulimit to not dump core? Or is that a bashism and not a shism?

The ulimit approach seems useful.

Blindly trying to remove a file named 'core' seems somewhat silly
since many OSs do not write a file named 'core'. Instead they write a
core file with some other file name or even write all core files to
some other directory on the system.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/

[Paul Eggert]

On 12/16/2012 07:06 AM, Bob Friesenhahn wrote:
>> Why not just use ulimit to not dump core? Or is that a bashism and not a shism?
>
> The ulimit approach seems useful.

Yes, that would be nice to add, if someone writes
a patch. I doubt whether it'd work everywhere, though.

> Instead they write a core file with some other file name

Autoconf-generated 'configure' scripts remove the commonly-used
file names for core files.

> or even write all core files to some other directory on the system.

It doesn't catch those.

[Bob Friesenhahn]

On Sat, 8 Dec 2012, Paul Eggert wrote:
>
> For your immediate problem, the simplest thing might be
> for you to rename the directory 'core', to 'Core', say.
> If that's not possible, you could run 'configure' in
> a subdirectory perhaps.

Renaming to 'Core' would likely not be suitable for Microsoft Windows
and other case-insensitive systems where 'Core' is treated the same as
'core'.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/

[Jeffrey Walton]

On Sat, Dec 8, 2012 at 3:37 PM, Bob Friesenhahn
<***@simple.dallas.tx.us> wrote:
> On Sat, 8 Dec 2012, Paul Eggert wrote:
>>
>> For your immediate problem, the simplest thing might be
>> for you to rename the directory 'core', to 'Core', say.
>> If that's not possible, you could run 'configure' in
>> a subdirectory perhaps.
>
> Renaming to 'Core' would likely not be suitable for Microsoft Windows and
> other case-insensitive systems where 'Core' is treated the same as 'core'.
Apple, too. https://www.google.com/#q=case+sensitive+filesystem+site:apple.com

[John Hawkinson]

autoconf should not help programmers write packages that
support "core" as a directory name. That's just going to cause
problems on traditional unix systems. Do not use directory
(or filenames) called "core" if your software is intended to be
portable!

This package should rename this directory.

--***@mit.edu
John Hawkinson