wrong GCC-configuration? (./specs: Is a directory)

[Steve Kreyer]

Hi,

only a guess:
Can it be, that gcc searches also in LIBRARY_PATH for the specs file ?
If so, maybe you have to check your LIBRARY_PATH environment variable,
if this contains a fullstop. Or maybe just play with it and find out how
gcc behaves to the content of this variable. Maybe you should set it to
/usr/lib/gcc/target/gcc-version directory, if this is the directory
where your default specs file is located.

Regards,
Steve

Ian Lance Taylor wrote:
> Karl Krach <mailinglists@blueSpirit.la> writes:
>
>   
>> Ian Lance Taylor wrote:
>>     
>>> Karl Krach <mailinglists@blueSpirit.la> writes:
>>>
>>>       
>>>> What I figured out: My problem is that my GCC reads the specs from the
>>>> current directory (if available).
>>>>         
>>> This is not normal behaviour.  There is something odd about your GCC.
>>> Or you've done something like set the environment variable
>>> GCC_EXEC_PREFIX to ".".
>>>       
>> I've already checked all environment variables. There is only
>> $GCC_SPECS and it's empty. But this variable (if empty) has no effect
>> to GCC's behavior.
>>     
>
> GCC_SPECS does nothing with standard gcc.
>
>   
>> And yes, I'm also sure that it's not the normal behavior. But I've no
>> idea which parameters to change.
>>     
>
> I think you must be using patched source code.  I have no other way of
> explaining what you are seeing.  Well, maybe you configured gcc with
> "--prefix=." but that would probably cause other problems.
>
> Ian
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://gcc.gnu.org/pipermail/gcc-help/attachments/20070328/ef11eb3d/attachment-0001.bin>