Comment 32 for bug 1113307

Revision history for this message
Dick Hollenbeck (dickelbeck) wrote : Re: [Bug 1113307] Re: Kicad build with scripting options (Debian Wheezy/Testing)

On 02/14/2013 12:57 PM, Wayne Stambaugh wrote:
> On 2/14/2013 1:29 PM, Dick Hollenbeck wrote:
>> On 02/14/2013 11:37 AM, Wayne Stambaugh wrote:
>>> On 2/14/2013 10:44 AM, Dick Hollenbeck wrote:
>>>> On 02/14/2013 09:30 AM, Dick Hollenbeck wrote:
>>>>> On 02/14/2013 08:48 AM, Wayne Stambaugh wrote:
>>>>>> I'm the process of compiling r3948 on MinGW on Windows and there is a
>>>>>> warning about -fPIC being ignored because all code is position
>>>>>> independent for every single source file that is compiled. I think this
>>>>>> is why -fPIC was not specified for MinGW builds on Windows. I'm not
>>>>>> sure if it's required for cross platform builds using MinGW.
>>>>> There is this:
>>>>>
>>>>> http://mingw.5.n7.nabble.com/Option-fPIC-not-supported-td18480.html
>>>>>
>>>>>
>>>>> and your windows mingw compiler warning to support the theory that on PE32 -fPIC is never
>>>>> needed.
>>>>>
>>>>> I get no warning when cross compiling from Linux to Mingw, but it is with gcc 4.6.3.
>>>>>
>>>>> I will commit a change to omit -fPIC on MINGW, and after we are actually calling a DLL
>>>>> from python or other, we can review this if needed.
>>>> http://sourceforge.net/mailarchive/message.php?msg_id=29650911
>>>>
>>>> Win64 may be out there in two forms, this is not a settled issue, IMO.
>>>>
>>> We know that we need position independent code.
>> No, not everyone knows this, and the compiler sure as hell does not know what the
>> intention of our use of any particular object file is.
>>
>> -fPIC is only needed in DSO's, period. The neither CMake nor the compiler has any idea
>> that an object file is going into a DSO, if the first place that object file goes is into
>> a static library.
> I guess I should have worded this differently. My intent is to used the
> compiler to determine if -fPIC is going to generate a warning message
> and excluded it from the C flags not as the test to determine if we need
> position independent code. This way if say MinGW64 doesn't generate a
> warning when -fPIC is set, we will not have to add another platform test
> to handle MinGW64 or any other platform where GCC supports position
> independent code.

Please no. As it stands the decision to use this flag is MY choice. I fixed the bug, did
I not? So arguably it is there because I chose to put it there, not the compiler, not the
operating, not some test, me.

Not some autotools like test, it was me.

Think of this setting as a bullet. It needs a target, and someone to aim it. You don't
simply put the gun on automatic and spin in a circle.

If I take my car in for a two tone paint job, I don't want the alternate colored paint on
other parts of the car. However, they body shop guy may say, "let me first paint the
whole car in the alternate color, then I will come back in and re-paint the other part of
the car in the original color." This is the state we are in. See my comment above the
-fPIC setting.

And when I aim it, I don't want to go looking for the paint gun.