specs question

specs question

[Iain Sandoe]

Hi.

My ‘downstream’ have a situation in which they make use of a directory outside of the configured GCC installation - and symlink from there to libraries in the actual install tree.

e.g.

/foo/bar/lib:
  libgfortran.dylib -> /gcc/install/path/lib/libgfortran.dylib

Now I want to find a way for them to add an embedded runpath that references /foo/bar/lib.

I could add a configure option, that does exactly this job - but then I’d have to back port that to every GCC version they are still supporting (not, perhaps, the end of the world but much better avoided).

So I was looking at using —with-specs= to add a link-time spec for this:

--with-specs='%{!nodefaultrpaths:%{!r:%:version-compare(>= 10.5 mmacosx_version_min= -Wl,-rpath,/foo/bar/lib)}}}’

Which works, fine except for PCH jobs which it breaks because the presence of an option claimed by the linker causes a link job to be created, even though one is not required (similar issue have been seen before).

There is this:
 %{,S:X}  substitutes X, if processing a file which will use spec S.

so I could then do:

--with-specs=‘%{,???:%{!nodefaultrpaths:%{!r:%:version-compare(>= 10.5 mmacosx_version_min= -Wl,-rpath,/foo/bar/lib)}}}}’

but, unfortunately, I cannot seem to figure out what ??? should be  [I tried ‘l’ (link_spec) ‘link_command’ (*link_command)]

…JFTR also tried
  %{!.h:
   %{!,c-header:

——
any insight would be welcome, usually I muddle through with specs, but this one has me stumped.

thanks
Iain

specs question.

[IainS]

what is the expected behavior of ?

%{.c|.cc|.for|.F90: foo }

.. as I read gcc/gcc.c I would expect to get "foo" for command lines  
with files with these suffixes:
.c
.cc
.for
.F90

but not otherwise (since it says . binds more strongly than |) ;

Iain

Re: specs question.

[Ian Lance Taylor]

IainS <developer@sandoe-acoustics.co.uk> writes:

> what is the expected behavior of ?
>
> %{.c|.cc|.for|.F90: foo }
>
> .. as I read gcc/gcc.c I would expect to get "foo" for command lines
> with files with these suffixes:
> .c
> .cc
> .for
> .F90
>
> but not otherwise (since it says . binds more strongly than |) ;

That sounds right to me.  Do you see something different?

Ian

Re: specs question.

[IainS]

On 12 Apr 2010, at 23:24, Ian Lance Taylor wrote:

> IainS <developer@sandoe-acoustics.co.uk> writes:
>
>> what is the expected behavior of ?
>>
>> %{.c|.cc|.for|.F90: foo }
>>
>> .. as I read gcc/gcc.c I would expect to get "foo" for command lines
>> with files with these suffixes:
>> .c
>> .cc
>> .for
>> .F90
>>
>> but not otherwise (since it says . binds more strongly than |) ;
>
> That sounds right to me.  Do you see something different

yeah .. we use it in Darwin's dsymutil spec.

%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
     %{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: \
    %{gdwarf-2:%{!gstabs*:%{!g0: dsymutil %{o*:%*}%{! 
o:a.out}}}}}}}}}}}}"
     %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} %{F*} }}}}}}}\n"


if you put "-lm" on the c/l dsymutil doesn't get called.

Almost as if ".m"  was being treated as a regex rather than a  
suffix... (but I don't think that's the whole story).

and I find that if I put .for|.f90 etc it makes no difference to  
fortran getting debugged...

---
... if I take away the %{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: }

It all works as expected...

----

I looked at the code (briefly) that parses the %{ } but it needs some  
time to digest what's going on - so I thought asking would be a good  
plan ;-)

Iain

Re: specs question.

[Ian Lance Taylor]

IainS <developer@sandoe-acoustics.co.uk> writes:

> yeah .. we use it in Darwin's dsymutil spec.
>
> %{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
>     %{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: \
>    %{gdwarf-2:%{!gstabs*:%{!g0: dsymutil %{o*:%*}%{!
> o:a.out}}}}}}}}}}}}"
>     %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} %{F*} }}}}}}}\n"
>
>
> if you put "-lm" on the c/l dsymutil doesn't get called.

Note that in the specs language the %{.XXX: ...} is matched against
the filename passed to the gcc driver.  It doesn't know the source
language of a .o file.  So if you are linking, and passing .o files,
then this approach won't work.

Ian

Re: specs question.

[IainS]

On 13 Apr 2010, at 00:22, Ian Lance Taylor wrote:

> IainS <developer@sandoe-acoustics.co.uk> writes:
>
>> yeah .. we use it in Darwin's dsymutil spec.
>>
>> %{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
>>    %{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: \
>>   %{gdwarf-2:%{!gstabs*:%{!g0: dsymutil %{o*:%*}%{!
>> o:a.out}}}}}}}}}}}}"
>>    %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} %{F*} }}}}}}}\n"
>>
>>
>> if you put "-lm" on the c/l dsymutil doesn't get called.
>
> Note that in the specs language the %{.XXX: ...} is matched against
> the filename passed to the gcc driver.  It doesn't know the source
> language of a .o file.  So if you are linking, and passing .o files,
> then this approach won't work.

well, my first question to myself was 'why are there not ".o" and ".a"  
in the list?'  ;))

There are two aspects to this ...
1/ the fact that this is probably not the right thing to do in that  
spec - easily solved by deleting it..

2/ The weird effect where putting -lm on the c/l causes the  
substitution to fail - which hints at a deeper problem.
FWIW I couldn't (quickly) find any other spec using that syntax - so  
perhaps it's not important.

cheers,
Iain

Re: specs question.

[Ian Lance Taylor]

IainS <developer@sandoe-acoustics.co.uk> writes:

> FWIW I couldn't (quickly) find any other spec using that syntax - so
> perhaps it's not important.

There is an example of in java/lang-specs.h.

%{.class|.zip|.jar|!fsyntax-only:jc1 ...

Ian

Re: specs question.

[IainS]

On 13 Apr 2010, at 00:22, Ian Lance Taylor wrote:
>> if you put "-lm" on the c/l dsymutil doesn't get called.
>
> Note that in the specs language the %{.XXX: ...} is matched against
> the filename passed to the gcc driver.  It doesn't know the source
> language of a .o file.  So if you are linking, and passing .o files,
> then this approach won't work.

(I saw your post about java .. I wasn't grepping the right things .. )

Since we're tagged onto the LINK_COMMAND_SPEC - this will get  
evaluated whenever that does.
... (not 100% sure when that is - when the driver is invoked or when  
the collect phase is invoked.. ).
.. also in_files and out_files can exhibit gotchas (e.g. anything  
beginning -l isn't eligible for treatments like %<lxx  I found recently)

---

It clearly depends on something no-obvious.

gcc hello.c  -g -o hc  => dsymutils gets run  (not expected from the  
syntax, assuming that sources are irrelevant)

gcc hello.o -g -o hc  => no dsymutils (expected from the absence of  
'.o' in the list)

gcc hello.c -g -o hc -lm => no dsymutils... (not at all expected ... )

adding .for to the list does not result in dsymutils getting run ..   
(expected by similarity, but not by logic)

removing the whole of the bracketed list -  results in all of those  
cases working.

I think the right local solution is to remove the expression (I'll run  
that by Mike Stump)...

I'm pursuing this in case there's a latent bug that should be reported.
cheers,
Iain

Re: specs question.

[Peter O'Gorman]

On 04/12/2010 07:01 PM, IainS wrote:

> 
> It clearly depends on something no-obvious.
> 
> gcc hello.c  -g -o hc  => dsymutils gets run  (not expected from the
> syntax, assuming that sources are irrelevant)
> 
> gcc hello.o -g -o hc  => no dsymutils (expected from the absence of '.o'
> in the list)

Hi Iain,

We don't want to run dsymutil if there are .o files, let the developer
do that.

If someone just does gcc -g -o foo foo.c, then any debugging information
will be lost when the temporary .o file is removed, thus, to allow
debugging such a foo, the compiler must run dsymutil.

Of course, it doesn't need to run for stabs, or -g0.

Strange, Apple's gcc-4.2 doesn't have this bug (-lm), yet that portion
of the specs appears identical.

Peter

Re: specs question.

[IainS]

On 13 Apr 2010, at 19:05, Peter O'Gorman wrote:

>> gcc hello.c  -g -o hc  => dsymutils gets run  (not expected from the
>> syntax, assuming that sources are irrelevant)
>>
>> gcc hello.o -g -o hc  => no dsymutils (expected from the absence of  
>> '.o'
>> in the list)

> We don't want to run dsymutil if there are .o files, let the developer
> do that.

OK, although AFAICT,
  it should be harmless doing it in the general case (and, to some  
extent, more friendly).

> If someone just does gcc -g -o foo foo.c, then any debugging  
> information
> will be lost when the temporary .o file is removed, thus, to allow
> debugging such a foo, the compiler must run dsymutil.

That's understood - although see below for a comment on Fortran***.

> Strange, Apple's gcc-4.2 doesn't have this bug (-lm), yet that portion
> of the specs appears identical.

indeed - although of course there's no reason to suppose that gcc/ 
gcc.c is identical in the two cases (I can check that at some stage)

My question has more to do with whether the apparent intention of the  
spec is being honored..
... and also why it doesn't work if I add more extensions (e.g. to  
extend coverage to Fortran, which Apple are not trying to cover in  
their case).

[***Even if I remove the %{.xxx.xxx.xx: } in the dsyutil section,  
there's a subsidiary issue with the Fortran case in that the debug  
info is only working if I put -save-temps on the CL].

cheers,
Iain