inode sharing problem

[Jianzhong Mo]

When I tried to compile an application, I got the following error message: "close.c shares inode with close.o. Can't overwrite source file". Here close.c is one of source file and close.o is its generated object file. Can anyone give me a clue to sovle this compile problem? Thanks.

[John Palmer]

It sounds as though the compiler has detected that close.c and close.o are actually hard links to the same file. That's why they share the same inode number.

Check with 'll -i close*' the first column is the inode number.

If they are indeed the same, I don't see why you just can't remove close.o as you a recreating it anyway.

[CHRIS_ANORUO]

Actually inodes are distinguished from other inodes by their file types.
Increase ninode at try again.

[John Palmer]

I can reproduce this error by simply linking .o to .c.

Simply removing .o cures the problem.

[Jianzhong Mo]

Hi John and Chris,

I doubled ninode number, but no luck. Actually close.o and close.c have different inode number. The source I tried to compile is DX-4.1.0. The makefiles are automatically generated which I changed the paths for some system libs only. The problem line of cc of one Makefile is followed:

( make usual_shared_object || make aix_shared_object )
cc -q -b -E -shared -o libAnyDX.so `ls ../dxl/*.o | sed -e "s&../dxl/object.o&&" -e "s&../dxl/x11.o&&"` DXLink.o
cc: warning 422: Unknown option "b" ignored.
cc: warning 422: Unknown option "h" ignored.
cc: warning 422: Unknown option "a" ignored.
cc: error 1411: "close.c" shares inode with "close.o". Can't overwrite source file.

../dxl/ is the directory where locates source code files which are compiled by a previous step of the whole compiling procedure. I don't know why the above cc line causes inode sharing problem.

Thanks.

[Pete Conneely]

Your warning 422 messages may indicate that your installation of the actual compiler is incorrect or that the cc compiler is corrupted and needs to be re-installed.

[tech1214]

It looks like you are using compiler arguments suitable for an AIX compiler, not an HP-UX compiler. The "-shared" and "-b" options are not valid for this compiler. In fact, it looks like the compiler is trying to parse each letter in the word "shared" as individual arguments (that's why it is complaining about 'h' and 'a' as being unknown options. Consequently, this means that the compiler is doing "-s -r -e -d" too, which is a weird mix. I am also suspicous of the -E option when it looks this step is basically a link step, so the pre-processor should not be involved.

I'd say whittle your options down to the bare minimum and see what happens.

[Jianzhong Mo]

Thanks for all of your inputs. I use aCC instead of cc to recompile the application. Then the inode sharing problem is gone. But I still don't know why.