ifort overwrites read-only executables.

[ryofurue]

Hi there,

I raised this as an "issue". There was a reply, but it was based on a misunderstanding and didn't answer my issue. I posted another message to clarify what I mean, but there was no reply to this message. So, here I raise the issue.

The issue is very simple: ifort overwrites read-only executables, which in my opinion it shouldn't. I'm attaching an example.

Because ifort (and ifc) overwrites my executables,
I made many mistakes. With other compilers I used to use, I protected myself from that type of mistakes by making executables read-only. I wish ifort not overwrite or erase existing read-only executables.

I'm using ifort on a Linux system.
Thank you,

Ryo
====================================
$ /opt/intel_fc_80/bin/ifort -V try.f90
Intel Fortran Compiler for 32-bit applications, Version 8.0 Build 20040412Z Package ID: installpackageid
Copyright (C) 1985-2004 Intel Corporation. All rights reserved.
FOR NON-COMMERCIAL USE ONLY

GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux
Supported emulations:
elf_i386
i386linux
$ chmod 444 a.out
$ ls -l
total 388
-r--r--r-- 1 furue iprc 384723 May 20 17:59 a.out
-rw-r--r-- 1 furue iprc 23 Apr 22 17:29 try.f90
-rw-r--r-- 1 furue iprc 29 Apr 22 17:30 try2.f90
amakihi[~/tmp/prob2]$ /opt/intel_fc_80/bin/ifort try2.f90
amakihi[~/tmp/prob2]$ ls -l
total 388
-rwxr-xr-x 1 furue iprc 384724 May 20 18:00 a.out*
-rw-r--r-- 1 furue iprc 23 Apr 22 17:29 try.f90
-rw-r--r-- 1 furue iprc 29 Apr 22 17:30 try2.f90
$

[Steven_L_Intel1]

What happens if you use ld separately to link the executable. I ask because it is ld, and not the compiler, that actually writes the executable. The compiler writes only the .o files.

My guess is that this is an ld behavior and your question should be directed towards the Linux maintainers.

[TimP]

If it's worth the trouble, you might change ownership of the files to increase the level of protection.

[ryofurue]

> What happens if you use ld separately to link the
> executable. I ask because it is ld, and not the
> compiler, that actually writes the executable. The
> compiler writes only the .o files.

Thanks for answering, Steve! You are correct, and how stupid of me not to have thought of that!

Although I don't know (and don't want to spend time to figure out) what options I should pass to ld to produce an executable from a .o file compiled by ifort, I've confirmed that ld actually removes the read-only a.out. Argh.

Perhaps I'll ask the authors of the GNU ld or I'll create a rapper script for ld to intersept attempts to overwrite read-only executables.

Thanks again,
Ryo

================================================
[This time I used ifc rather than ifort.]
$ ld --version
GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux
[...snip...]
$ ls -l a.out
-r--r--r-- 1 furue iprc 260663 May 21 08:59 a.out
$ ld try.o
ld: warning: cannot find entry symbol _start; defaulting to 08048074
try.o: In function `main':
try.o(.text+0x14): undefined reference to `f90_init'
[...snip...]
$ ls -l a.out
ls: a.out: No such file or directory
$