Hi Richard
(* I am weak in English, so pleas forgive my English mistake.)
Thank you for your reply, and I'm sorry to be late a reply.
> On Sat, Mar 20, 2010 at 5:40 PM, Tadashi Koike <tadash...@gmail.com> wrote:
>> [ summary ]
>> compiling is failed when more than two source file are
>> specified with both -save-temps=obj and -o options.
:
>> [[ operations being error ]]
>> % gcc -save-temps=obj -o hellow main.c func.c
>> % gcc -save-temps=obj -o obj_dir/hellow main.c func.c
2010/3/21 Richard Guenther <richard.guent...@gmail.com>:
>
> It should be an error to use -save-temps=obj with multiple
> input files. Mike, can you look at this?
>
> Thanks,
> Richard.
>
After I received your reply, I confirm an information about "-save-temps=obj".
In this URL(http://gcc.gnu.org/gcc-4.5/changes.html), "-save-temps=obj"
option are introduced as follow:
| The -save-temps=obj switch will write files into the directory specified
| with the -o option, and the intermediate filenames are based on the
| output file.
If above is a specification of "-save-temps=obj" option, found behaviors
in my report about "-save-temps=obj" are true behaviors (but cannot
deal in case of multiple input files).
I considered. And I read a purpose of this option in above URL :
| This will allow the user to get the compiler intermediate files when
| doing parallel builds without two builds of the same filename located in
| different directories from interfering with each other.
My recognition is below:
- True purpose is a failure of compiling under parallel builds. In detail,
problem is a compiling failure under parallel builds caused by interfering
intermediate file each other. To solve this problem, developer thought
that the intermediate files have to be created in different directory.
So a directory specified with the -o option are choose as these purpose.
(I named this problem as "Compiling failure by interfering" for following
discussion.)
- If two builds of the same file name located in different directories are
done as serial, each build is successful fine, but intermediate file is
overwritten by a latest compiling.
(I named this problem as "Overwritten by interfering" for following
discussion.)
- A purpose of "-save-temps=obj" option is to solve the "Compiling
failure by interfering", not to solve the "Overwritten by interfering".
>From my consideration, I reached some understanding as follow:
- True solution for "Compiling failure by interferng" is using a
true independent file name which is assured by System (such as
filename returned by tmpnam() function in stdio.h) for each
intermediate file. After compiling are successful, filename of
intermediate files need to change as true filenames based on
source/object files.
- "-save-temps=obj" option is useful to solve some "Overwritten
by interfering" problems. Trouble will decrease caused this
problem. (so I hope/want this option very much)
- I hope that the filename of intermediate file by "-save-temps=obj"
is also based on source files.
I hope to hear someone's opinion else.
Best regards,
Tadashi Koike
2010/3/21 Richard Guenther <richard.guent...@gmail.com>:
> On Sat, Mar 20, 2010 at 5:40 PM, Tadashi Koike<tadash...@gmail.com> wrote:
>> Hi all,
>> (* I am weak in English, so pleas forgive my English mistake.)
>>
>> Please teach me about a behavior of -save-temps=obj option
>> on gcc 4.5. A behavior I found is whether bug or specification ?
>>
>> [ summary ]
>> compiling is failed when more than two source file are
>> specified with both -save-temps=obj and -o options.
>>
>> 1) Environment
>> -------------------------------------------------------
>> [System]: Fedora release 12 (Constantine)
>> [gcc version]:
>> % /usr/local/bin/gcc -v
>> Using built-in specs.
>> COLLECT_GCC=/usr/local/bin/gcc
>>
>> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
>> Target: x86_64-unknown-linux-gnu
>> Configured with: ../gcc-4.5-20100304-src/configure
>> --prefix=/usr/local --mandir=/usr/local/share/man
>> --infodir=/usr/local/share/info --enable-languages=c,c++ --disable-nls
>> Thread model: posix
>> gcc version 4.5.0 20100304 (experimental) (GCC)
>> -------------------------------------------------------
>>
>> 2) Source files I used are bellow:
>> [main.c]
>> +------------------------------------------------------
>> |extern int func(const char *);
>> |int main () {
>> | func("hello world!\n");
>> |}
>> +------------------------------------------------------
>> [func.c]
>> +------------------------------------------------------
>> |#include<stdio.h>
>> |int func (const char *str) {
>> | return(fprintf(stdout, str));
>> |}
>> +------------------------------------------------------
>>
>> 3) Files/Directory structure is bellow:
>> /tmp/test/hellow.c
>> /func.c
>> /obj_dir/
>>
>> 4) Test operations.
>> I tryed bellow operations at /tmp/test directory.
>> -------------------------------------------------------
>> [[ operations being successful ]]
>> % gcc main.c func.c
>> % gcc -o obj_dir/hello main.c func.c
>> % gcc -save-temps=cwd main.c func.c
>> % gcc -save-temps=cwd -o obj_dir/hello main.c func.c
>> % gcc -save-temps=obj main.c func.c
>>
>> [[ operations being error ]]
>> % gcc -save-temps=obj -o hellow main.c func.c
>> % gcc -save-temps=obj -o obj_dir/hellow main.c func.c
>>
>> // example error messages //
>> obj_dir/hello.o: In function `func':
>> func.c:(.text+0x0): multiple definition of `func'
>> obj_dir/hello.o:func.c:(.text+0x0): first defined here
>> /usr/lib/../lib64/crt1.o: In function `_start':
>> (.text+0x20): undefined reference to `main'
>> collect2: ld returned 1 exit status
>>
>> // more information//
>> * in this error case, temporary files are nemed as
>> 'hello.i' and that content is from 'func.c', but
>> contents of 'hello.s' is perhaps from 'main.c'.
>> -------------------------------------------------------
>>
>> I think that two understanding are possible.
>> A) this behavior is a specification like '-o' option with
>> using -c option.
>>
>> [ operation example ]
>> % gcc -c -o obj_dir/hello.o main.c func.c
>> gcc: cannot specify -o with -c, -S or -E with multiple files
>>
>> B) this behavior is a bug.
>> [ reason ]
>> In below case, temporary files are made in current
>> directory. names of these files are based on 'source
>> file'.
>>
>> % gcc -save-temps=cwd -o obj_dir/hello main.c func.c
>>
>> When -save-temps=cwd option is exchanged to
>> -save-temps=obj, I expect to keep names of temporary
>> files as from 'source file', and only a place to save
>> temporary files are exchanged to object directory.
>>
>> Because I don't understand that this behavior is whether
>> bug or specification, so I don't report this to bugzilla
>> yet.
>>
>> I feel that function of -save-temps=obj option is great!
>> I would like to know how to use -save-temps=obj option.
>> So pleas teach me true behavior about -save-temps=obj.
>
> It should be an error to use -save-temps=obj with multiple
> input files. Mike, can you look at this?
>
> Thanks,
> Richard.
>
>> Best regards,
>> Tadashi Koike
>>
>
