Kicad build with scripting options (Debian Wheezy/Testing)

[Olivier (osfe)]

Hi there,
I just compiled kicad rev 3927 on debian wheezy. The build process with script options goes smoothly if you do create a simlink python2 -> python2.6 bofore building. Though when I try to load the pcbnew class from a python terminal, I get the following error:
olivier@debian:~$ python2.6
Python 2.6.8 (unknown, Jun 25 2012, 17:08:48)
[GCC 4.7.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pcbnew
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.6/dist-packages/pcbnew.py", line 29, in <module>
    import _pcbnew
ImportError: No module named _pcbnew
Obviously pcbnew.py is found but something goes wrong during loading the module.

Thank you very much for your help

Regards,

Olivier

[Wayne Stambaugh (stambaughw)]

I already have this fixed and as soon as I get my computer situation sorted out I will commit the change.

[Olivier (osfe) (olivier-lemaire-osfe)]

Can't wait !! :)
Thank you for your answer.

[Wayne Stambaugh (stambaughw)]

Oliver,

I just committed the changes that should fix this. You will have to run make install as root to install the Python modules unless you install them where you have permissions. If you are unsure of running make install this way, you can manually copy pcbnew.py and _pcbnew.pyd to your Python site package path as root. You can find out where make install would have installed them by entering "grep PYTHON_DEST < CMakeCache.txt" in your build path. Let me know if this works for you. Thanks for helping to improve KiCad.

Wayne

[Olivier (osfe) (olivier-lemaire-osfe)]

Hi Wayne,
here is the result:
# cmake -DKICAD_TESTING_VERSION=ON -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON ../
-- The C compiler identification is GNU 4.7.2
-- The CXX compiler identification is GNU 4.7.2
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
Build testing (unstable) version of KiCad
-- Setting GCC version 4.7 build flags "-Wno-narrowing -O1"
-- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so
-- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib/x86_64-linux-gnu/libX11.so
-- Check for installed OpenGL -- found
-- Check for installed wxWidgets -- found
-- Looking for malloc.h
-- Looking for malloc.h - found
-- Looking for iso646.h
-- Looking for iso646.h - found
-- Looking for strcasecmp
-- Looking for strcasecmp - found
-- Looking for strncasecmp
-- Looking for strncasecmp - found
-- Looking for malloc
-- Looking for malloc - found
-- Looking for _stricmp
-- Looking for _stricmp - not found.
-- Looking for _strnicmp
-- Looking for _strnicmp - not found.
-- Looking for _snprintf
-- Looking for _snprintf - not found.
-- Looking for math.h
-- Looking for math.h - found
-- Looking for _hypot
-- Looking for _hypot - not found.
-- Looking for C++ include cmath
-- Looking for C++ include cmath - found
-- Looking for asinh
-- Looking for asinh - found
-- Looking for acosh
-- Looking for acosh - found
-- Looking for atanh
-- Looking for atanh - found
-- Performing Test HAVE_CMATH_ISINF
-- Performing Test HAVE_CMATH_ISINF - Success
-- Looking for clock_gettime in rt
-- Looking for clock_gettime in rt - found
-- Looking for gettimeofday
-- Looking for gettimeofday - found
-- Looking for getc_unlocked
-- Looking for getc_unlocked - found
-- Found PythonInterp: /usr/bin/python (found version "2.7.3")
-- Check for installed Python Interpreter -- found
-- Python module install path: /usr/lib/python2.7/dist-packages
-- Found PythonLibs: /usr/lib/libpython2.7.so (found version "2.7.3")
-- Bazaar version control system version found.
-- Kicad Bazaar build version: (2013-02-10 BZR 3941)
-- Found SWIG: /usr/bin/swig2.0 (found version "2.0.7")
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.1.2")
-- Configuring done
-- Generating done
-- Build files have been written to: /opt/kicad/build
# make -j2
[...]
[ 93%] Building CXX object pcbnew/CMakeFiles/_pcbnew.dir/class_footprint_wizard.cpp.o
[ 94%] Building CXX object pcbnew/CMakeFiles/pcbnew.dir/muwave_command.cpp.o
[ 94%] Building CXX object p...

[Wayne Stambaugh (stambaughw)]

I just compiled this on 64 bit Debian/Wheezy without any issues. I used ipython and imported pcbnew without any problems. Try running make clean or completely rebuilding KiCad. There may be some issues since Boost was just updated to 1.53.

[Dick Hollenbeck (dickelbeck)]

On 02/11/2013 06:59 PM, Wayne Stambaugh wrote:
> I just compiled this on 64 bit Debian/Wheezy without any issues. I used
> ipython and imported pcbnew without any problems. Try running make
> clean or completely rebuilding KiCad. There may be some issues since
> Boost was just updated to 1.53.
>

If you need some fall back theory, consider this as such (since I did not check the
CMakeLists.txt file about this):

This could be a difference in binutils versions, and the error message may actually be
correct.

On x86_64 platforms any objects going into a DSO should be compiled with -fPIC.

Not so important on x86.

In any case since this code is not called from python, it has not blown up yet, the
3d-viewer is never called.
Obviously some of the code in _pcbnew.so is compiled correctly, otherwise it would have
crashed.

Binutils is just giving us an early warning.

[Olivier (osfe) (olivier-lemaire-osfe)]

Hi guys,
I just went through an aptitude updade and aptitude safe-upgrade.
I tried to compile the very last branch (rev 3943)
One more time the compilation fails... Here is the build log:
https://docs.google.com/file/d/0BwVeEbMT_YtDclFLdWY5bHdHZUE/edit?usp=sharing
Maybe I should upgrade boost to 1.53 ?

[Olivier (osfe) (olivier-lemaire-osfe)]

Just a small detail, I changed python2->python2.6 to python2->python2.7

[Wayne Stambaugh (stambaughw)]

On 2/11/2013 9:05 PM, Dick Hollenbeck wrote:
> On 02/11/2013 06:59 PM, Wayne Stambaugh wrote:
>> I just compiled this on 64 bit Debian/Wheezy without any issues. I used
>> ipython and imported pcbnew without any problems. Try running make
>> clean or completely rebuilding KiCad. There may be some issues since
>> Boost was just updated to 1.53.
>>
>
>
> If you need some fall back theory, consider this as such (since I did not check the
> CMakeLists.txt file about this):
>
>
> This could be a difference in binutils versions, and the error message may actually be
> correct.
>
> On x86_64 platforms any objects going into a DSO should be compiled with
> -fPIC.
>
> Not so important on x86.
>
> In any case since this code is not called from python, it has not blown up yet, the
> 3d-viewer is never called.
> Obviously some of the code in _pcbnew.so is compiled correctly, otherwise it would have
> crashed.
>
> Binutils is just giving us an early warning.
>

The -fPIC option is set when compiling with GCC on Linux. I'm wondering
if Oliver's change from python 2.6 to python 2.7 between builds had
anything to do with it. I compiled and linked against python 2.7.3
without any problems including the change over to Boost 1.53. Python
2.7.3 is the current default in Debian Wheezy.

[Wayne Stambaugh (stambaughw)]

On 2/12/2013 5:18 AM, m.olivier.lemaire wrote:
> Hi guys,
> I just went through an aptitude updade and aptitude safe-upgrade.
> I tried to compile the very last branch (rev 3943)
> One more time the compilation fails... Here is the build log:
> https://docs.google.com/file/d/0BwVeEbMT_YtDclFLdWY5bHdHZUE/edit?usp=sharing
> Maybe I should upgrade boost to 1.53 ?
>
Hey Oliver,

You do not need to upgrade Boost on your system. KiCad includes it's
own subset of the Boost header libraries. This was done a few years ago
to prevent Boost version availability issues between Linux distros and
install issues on Windows which created a lot headaches. When you
updated your KiCad source to r3939 or later, Boost 1.53 was included.
Please send me the cmake command line you used to configure your build
so I can build with the same configuration. You should be able to copy
it from you ~/.bash_history file. Are you setting any GCC environment
variables that could possibly overriding the default settings?

Thanks,

Wayne

[Olivier (osfe) (olivier-lemaire-osfe)]

The cmake I commad I use is the following:
cmake -DKICAD_TESTING_VERSION=ON -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON ../
I don't think I use any special variable(s)...

Here is the way I use to build kicad:
# bzr update
# cd build/
# make uninstall
# rm -fR ./*
# cmake -DKICAD_TESTING_VERSION=ON -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON ../
# make -j2 | tee build.log

[Dick Hollenbeck (dickelbeck)]

>> Binutils is just giving us an early warning.

> The -fPIC option is set when compiling with GCC on Linux.

The text of the error message is this:

[ 94%] Building CXX object pcbnew/CMakeFiles/pcbnew.dir/netlist_reader_common.cpp.o
Linking CXX shared module _pcbnew.so
/usr/bin/ld: ../3d-viewer/lib3d-viewer.a(3d_aux.cpp.o): relocation R_X86_64_32 against
`.rodata' can not be used when making a shared object; recompile with -fPIC
../3d-viewer/lib3d-viewer.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [pcbnew/_pcbnew.so] Error 1

It clearly points to 3d_aux.cpp.o.

So delete that one file, mentioned above. Then do:

$ make VERBOSE=1 _pcbnew.so > capture.txt

The verify the -fPIC is actually in there, on the command line.

If it is, then the binutils ld program may have a bug in it. If it is not, then our
CMakeLists.txt has a bug.

> I'm wondering
> if Oliver's change from python 2.6 to python 2.7 between builds had
> anything to do with it.

$ ldd _pcbnew.so | grep python
    libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0x00007fb45a36b000)

A dynamic link to Python is in _pcbnew.{pyd,so}

But the error message says nothing about this, and the link is dynamic, so I doubt it.

> I compiled and linked against python 2.7.3
> without any problems including the change over to Boost 1.53. Python
> 2.7.3 is the current default in Debian Wheezy.

[Olivier (osfe) (olivier-lemaire-osfe)]

Hi Dick,
thank you for your answer. If I may, can you please clarify if you're talking to Wayne or me.

Regards,

Olivier

[Dick Hollenbeck (dickelbeck)]

Anyone on linux can try it, *especially you*. Your results seem to be unique.
No one is duplicating your problem, so your toolchain and development environment is on the suspicious list.

[Olivier (osfe) (olivier-lemaire-osfe)]

ok... I feel a little stupid now...
Concerning make VERBOSE=1 _pcbnew > capture.txt
it gives:
/usr/bin/cmake -H/opt/kicad/kicad.bzr -B/opt/kicad/kicad.bzr/build --check-build-system CMakeFiles/Makefile.cmake 0
make -fPIC CMakeFiles/Makefile2 _pcbnew
make[1]: Entering directory `/opt/kicad/kicad.bzr/build'
make[1]: Leaving directory `/opt/kicad/kicad.bzr/build'

Just to let you know, I tried on 2 different computers, both with wheezy...

[Dick Hollenbeck (dickelbeck)]

On 02/12/2013 01:49 PM, m.olivier.lemaire wrote:
> ok... I feel a little stupid now...
> Concerning make VERBOSE=1 _pcbnew > capture.txt
> it gives:
> /usr/bin/cmake -H/opt/kicad/kicad.bzr -B/opt/kicad/kicad.bzr/build --check-build-system CMakeFiles/Makefile.cmake 0
> make -fPIC CMakeFiles/Makefile2 _pcbnew
> make[1]: Entering directory `/opt/kicad/kicad.bzr/build'
> make[1]: Leaving directory `/opt/kicad/kicad.bzr/build'
>
> Just to let you know, I tried on 2 different computers, both with
> wheezy...
>

I tried it too, and here is the portion of the output of interest, in full:

$ find -name 3d_aux.cpp.o
./3d-viewer/CMakeFiles/3d-viewer.dir/3d_aux.cpp.o

$ rm `find -name 3d_aux.cpp.o`

At this point, this directory has already successfully built everything, so the only
missing binary is 3d_aux.cpp.o, so it will get built first as we try again:

$ make VERBOSE=1 _pcbnew > capture.txt

Relevant portion:

===========================================================================
[ 0%] Building CXX object 3d-viewer/CMakeFiles/3d-viewer.dir/3d_aux.cpp.o

cd /svn/kicad/testing.checkout/build/3d-viewer && /usr/bin/c++
-DKICAD_TESTING_VERSION -DKICAD_SCRIPTING -DKICAD_SCRIPTING_MODULES
-DKICAD_SCRIPTING_WXPYTHON -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__
-DHAVE_SVN_VERSION -DPCBNEW -pthread -Wall -g3 -ggdb3 -DDEBUG -fPIC
-I/svn/kicad/testing.checkout/include -I/svn/kicad/testing.checkout/3d-viewer/.
-isystem /usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-release-2.8 -isystem
/usr/include/wx-2.8 -I/usr/include/python2.7
-I/svn/kicad/testing.checkout/./scripting
-I/svn/kicad/testing.checkout/3d-viewer/../pcbnew
-I/svn/kicad/testing.checkout/3d-viewer/../polygon
-I/svn/kicad/testing.checkout/build -o CMakeFiles/3d-viewer.dir/3d_aux.cpp.o -c
/svn/kicad/testing.checkout/3d-viewer/3d_aux.cpp

Linking CXX static library lib3d-viewer.a
==========================================================================

Isee -fPIC in there.

If I grab the portion of the compiler from this output, to verify I am running a 64 bit
compiler(make no assumptions):

$ /usr/bin/c++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/c++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6
--enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror
--with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

The key line is
Target: X86_64-linux-gnu

==========================================================================

I think this is *not* a KiCad ...

[Dick Hollenbeck (dickelbeck)]

You may have a munged (poorly patched) tool in play:

candidates:

a) cmake b) gcc c) make d) binutils.

You could modify your make command line to ignore errors, build all that it can, then delete only that one file.

Then compare the output of your capture to mine, attached.

[Olivier (osfe) (olivier-lemaire-osfe)]

I know this information does not give any further information build here is my last full build log
cmake -DKICAD_TESTING_VERSION=ON -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON ../
make VERBOSE=1 -j4 2>&1 | tee build.log

 I feel like this problem is going way above my knowledge...

regards,

Olivier

[Dick Hollenbeck (dickelbeck)]

On 02/13/2013 02:21 PM, m.olivier.lemaire wrote:
> I know this information does not give any further information build here is my last full build log
> cmake -DKICAD_TESTING_VERSION=ON -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON ../
> make VERBOSE=1 -j4 2>&1 | tee build.log
>
> I feel like this problem is going way above my knowledge...
>
> regards,
>
> Olivier
>
> ** Attachment added: "build log"
> https://bugs.launchpad.net/kicad/+bug/1113307/+attachment/3527253/+files/build.log

I found the problem. The -fPIC option is not being sent to the command line option of the
3d_aux.cpp compile, so the error message was correct.

add this to your command line:

-DCMAKE_BUILD_TYPE=Release

The error message was correct. My instruction to you was correct. The line you needed to
inspect is as follows:

cd /opt/kicad_test_script/kicad.bzr/build/3d-viewer && /usr/bin/c++
-DKICAD_TESTING_VERSION -DKICAD_SCRIPTING -DKICAD_SCRIPTING_MODULES
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -DHAVE_SVN_VERSION -DPCBNEW
-pthread -I/opt/kicad_test_script/kicad.bzr/include
-I/opt/kicad_test_script/kicad.bzr/3d-viewer/. -isystem
/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-release-2.8 -isystem
/usr/include/wx-2.8 -I/usr/include/python2.7
-I/opt/kicad_test_script/kicad.bzr/./scripting
-I/opt/kicad_test_script/kicad.bzr/3d-viewer/../pcbnew
-I/opt/kicad_test_script/kicad.bzr/3d-viewer/../polygon
-I/opt/kicad_test_script/kicad.bzr/build -o
CMakeFiles/3d-viewer.dir/3d_aux.cpp.o -c
/opt/kicad_test_script/kicad.bzr/3d-viewer/3d_aux.cpp

No -fPIC.

[Dick Hollenbeck (dickelbeck)]

I changed CMakeLists.txt to supply this option for CMAKE_BUILD_TYPE not equal to Release or Debug.

[Wayne Stambaugh (stambaughw)]

I would have thought CMake would have defaulted to something reasonable when no build type is specified. This is why I didn't see the issue. I always specify the build type. Is this possibly an issue with CMake or does the build type default to one of the types (RELWITHDEBINFO or MINSIZEREL) were we didn't define -fPIC?

[Wayne Stambaugh (stambaughw)]

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.

[Dick Hollenbeck (dickelbeck)]

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.

[Wayne Stambaugh (stambaughw)]

I did a little bit of digging around and found that CMAKE_BUILD_TYPE is empty when you don't specify it when you run CMake. I also found this comment in the CMakeCache.txt after running CMake with no build type defined:

//Choose the type of build, options are: None(CMAKE_CXX_FLAGS or
// CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.
CMAKE_BUILD_TYPE:STRING=

This would suggest that the CMAKE_C(XX)_(CMAKE_BUILD_TYPE)_FLAGS are no longer in play when a build type is not defined. This also means that the RELWITHDEBINFO and MINSIZEREL build types would have also failed before your latest changes. What I am not sure of is if the CMAKE_C(XX)_FLAGS are concatenated with the CMAKE_C(XX)_(CMAKE_BUILD_TYPE)_FLAGS when a build type is defined. If they are then we can simplify the GCC option code in CMakeList.txt. If not, we will have to add the GCC flags for the RELWITHDEBINFO and MINSIZEREL build types. Otherwise, this problem rear is head again if someone used those build types. I'm surprised it took this long for this to show up.

[Dick Hollenbeck (dickelbeck)]

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.

[Dick Hollenbeck (dickelbeck)]

On 02/14/2013 09:38 AM, Wayne Stambaugh wrote:
> I did a little bit of digging around and found that CMAKE_BUILD_TYPE is
> empty when you don't specify it when you run CMake. I also found this
> comment in the CMakeCache.txt after running CMake with no build type
> defined:
>
> //Choose the type of build, options are: None(CMAKE_CXX_FLAGS or
> // CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.
> CMAKE_BUILD_TYPE:STRING=
>
> This would suggest that the CMAKE_C(XX)_(CMAKE_BUILD_TYPE)_FLAGS are no
> longer in play when a build type is not defined. This also means that
> the RELWITHDEBINFO and MINSIZEREL build types would have also failed
> before your latest changes. What I am not sure of is if the
> CMAKE_C(XX)_FLAGS are concatenated with the
> CMAKE_C(XX)_(CMAKE_BUILD_TYPE)_FLAGS when a build type is defined.

This is my understanding, CMAKE_C(XX)_FLAGS are always in play, regardless of
CMAKE_BUILD_TYPE, if any.

Remember that there can also be custom build types, so the set of build types is therefore
infinite.

Historically I have only used 3: "", Debug, Release.

> If
> they are then we can simplify the GCC option code in CMakeList.txt. If
> not, we will have to add the GCC flags for the RELWITHDEBINFO and
> MINSIZEREL build types. Otherwise, this problem rear is head again if
> someone used those build types. I'm surprised it took this long for
> this to show up.

Not a lot of folks build the python stuff yet, so not a lot of DSOs are being linked.

Even fewer should be actually called, (since the the DSO is technically not needed when
running python from within Pcbnew, only when running python on the command line, calling
kicad functions without having started pcbnew.)
So we might find more problems in this least used path later.

[Olivier (osfe) (olivier-lemaire-osfe)]

cmake -DCMAKE_BUILD_TYPE=Release -DKICAD_TESTING_VERSION=ON -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON ../
make VERBOSE=1 -j2 2>&1 | tee build.log

I feel like crying...

[Olivier (osfe) (olivier-lemaire-osfe)]

I fixed a problem with python libs ans now it compiles...
I can import the pcbnew module from an ipython terminal...
Thank you so much to all of you for your precious help!!

[Wayne Stambaugh (stambaughw)]

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. It appears that GCC
also knows when -fPIC is valid and when it is not. We should be able to
use GCC to tell us if the -fPIC flag generates a warning for a given
platform. I just hacked up check_c_compiler_flag() in CMakeList.txt and
on MinGW32 on Windows it returns a non-zero value which is what I
expected. I still need to confirm that it returns a zero value on Linux
before I commit the change. This should eliminate any need in the
future to add more platform if()/endif() test statements which will
simplify CMakeList.txt and put this issue to rest (at least for GCC). I
think there are a few other GCC flags were we use platform tests instead
of using the compiler to tell us if we should use an option flag or not.
 I will chip at these over the next few days.

[Dick Hollenbeck (dickelbeck)]

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.

> It appears that GCC
> also knows when -fPIC is valid and when it is not.

No, it only knows when it will accept the option. This may have nothing to do with need.

> We should be able to
> use GCC to tell us if the -fPIC flag generates a warning for a given
> platform. I just hacked up check_c_compiler_flag() in CMakeList.txt and
> on MinGW32 on Windows it returns a non-zero value which is what I
> expected. I still need to confirm that it returns a zero value on Linux
> before I commit the change. This should eliminate any need in the
> future to add more platform if()/endif() test statements which will
> simplify CMakeList.txt and put this issue to rest (at least for GCC). I
> think there are a few other GCC flags were we use platform tests instead
> of using the compiler to tell us if we should use an option flag or not.
> I will chip at these over the next few days.

The CMakeLists.txt file looked fine when I committed it.

I am not in favor of hiding important choices in hard to find places.

[Wayne Stambaugh (stambaughw)]

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.

>
>
>> It appears that GCC
>> also knows when -fPIC is valid and when it is not.
>
> No, it only knows when it will accept the option. This may have nothing
> to do with need.
>
>> We should be able to
>> use GCC to tell us if the -fPIC flag generates a warning for a given
>> platform. I just hacked up check_c_compiler_flag() in CMakeList.txt and
>> on MinGW32 on Windows it returns a non-zero value which is what I
>> expected. I still need to confirm that it returns a zero value on Linux
>> before I commit the change. This should eliminate any need in the
>> future to add more platform if()/endif() test statements which will
>> simplify CMakeList.txt and put this issue to rest (at least for GCC). I
>> think there are a few other GCC flags were we use platform tests instead
>> of using the compiler to tell us if we should use an option flag or not.
>> I will chip at these over the next few days.
>
> The CMakeLists.txt file looked fine when I committed it.
>
> I am not in favor of hiding important choices in hard to find places.
>

[Dick Hollenbeck (dickelbeck)]

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.

[Dick Hollenbeck (dickelbeck)]

Basically, this paint gun should not be installed up on an arm like in a car wash, where
it is out of reach of the operator.

There is no tool or automatic test that can make this particular choice for us at this point.

This is because CMake is incapable of knowing that a static library is DSO destined,
especially if that static library is *also* executable destined.

Normally CMake does and can provide this flag behind the scenes. This is when the
intermediate static library is not in the picture.

Here, we can rely on experience to decide, but only if the tuning knobs are within reach.

Dick

[Wayne Stambaugh (stambaughw)]

On 2/14/2013 2:35 PM, Dick Hollenbeck wrote:
> Basically, this paint gun should not be installed up on an arm like in a car wash, where
> it is out of reach of the operator.
>
>
> There is no tool or automatic test that can make this particular choice for us at this point.
>
> This is because CMake is incapable of knowing that a static library is DSO destined,
> especially if that static library is *also* executable destined.
>
>
> Normally CMake does and can provide this flag behind the scenes. This is when the
> intermediate static library is not in the picture.
>
>
> Here, we can rely on experience to decide, but only if the tuning knobs are within reach.
>
>
> Dick
>
I agree with everything you've said here. We as developers have to
determine when position independent code is required, not the compiler
or CMake or any other tool for that matter. What we do not get any say
in is on what platforms and/or versions of GCC will generate a compiler
warning when -fPIC is set. The GCC developers have that say and can
change it at their discretion. I am merely suggesting that when we as
developers decide that we need position independent code that we test if
using the GCC -fPIC flag will cause compiler warnings and exclude it
accordingly. We are already doing this indirectly by checking for MinGW
versus any other platform when compiling with GCC. I have no idea if
-fPIC will generate a warning on MinGW64, OSX, ARM, etc. until I
actually perform a build on those platforms but the compiler does. What
happens in the future as new platforms and versions of GCC become
available? We may have to change our CMake code for each case that did
not fit with our current tests and we could end up with a very complex
platform/GCC version testing scheme to handle each unique case. My
thinking is that testing -fPIC will decouple the platform and the GCC
version variations from our CMake configuration which is generally a
good thing. I will not add this if you are against it. I'm just
failing to see the down side.

Wayne

[Dick Hollenbeck (dickelbeck)]

I am against it, thanks.
Had this information been hidden in an include this morning, I would have
lost interest and never spent enough time to have found the bug.

Only dso objs need this flag, so forget your concerns about windows, and
concerns about other compilers.

Eventually pcbnew will only exist in dso/dll form and things will fall out
cleaner.
On Feb 14, 2013 3:05 PM, "Wayne Stambaugh" <email address hidden>
wrote:

> On 2/14/2013 2:35 PM, Dick Hollenbeck wrote:
> > Basically, this paint gun should not be installed up on an arm like in a
> car wash, where
> > it is out of reach of the operator.
> >
> >
> > There is no tool or automatic test that can make this particular choice
> for us at this point.
> >
> > This is because CMake is incapable of knowing that a static library is
> DSO destined,
> > especially if that static library is *also* executable destined.
> >
> >
> > Normally CMake does and can provide this flag behind the scenes. This
> is when the
> > intermediate static library is not in the picture.
> >
> >
> > Here, we can rely on experience to decide, but only if the tuning knobs
> are within reach.
> >
> >
> > Dick
> >
> I agree with everything you've said here. We as developers have to
> determine when position independent code is required, not the compiler
> or CMake or any other tool for that matter. What we do not get any say
> in is on what platforms and/or versions of GCC will generate a compiler
> warning when -fPIC is set. The GCC developers have that say and can
> change it at their discretion. I am merely suggesting that when we as
> developers decide that we need position independent code that we test if
> using the GCC -fPIC flag will cause compiler warnings and exclude it
> accordingly. We are already doing this indirectly by checking for MinGW
> versus any other platform when compiling with GCC. I have no idea if
> -fPIC will generate a warning on MinGW64, OSX, ARM, etc. until I
> actually perform a build on those platforms but the compiler does. What
> happens in the future as new platforms and versions of GCC become
> available? We may have to change our CMake code for each case that did
> not fit with our current tests and we could end up with a very complex
> platform/GCC version testing scheme to handle each unique case. My
> thinking is that testing -fPIC will decouple the platform and the GCC
> version variations from our CMake configuration which is generally a
> good thing. I will not add this if you are against it. I'm just
> failing to see the down side.
>
> Wayne
>
> --
> You received this bug notification because you are a member of KiCad Bug
> Squad, which is subscribed to KiCad.
> https://bugs.launchpad.net/bugs/1113307
>
> Title:
> Kicad build with scripting options (Debian Wheezy/Testing)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1113307/+subscriptions
>

[Dick Hollenbeck (dickelbeck)]

> I'm just failing to see the down side. Wayne

It could just be me, but I don't think so. I would no sooner take instruction from my
C++ comnpiler on how to program than I would ask my toothbrush whether I should brush up
or down.

Instead, if I had questions, I would ask someone with a lot of experience brushing teeth,
like my Dad or my dentist, or a friend at least as old as I am.

Then, I would go try that technique with my toothbrush. If the toothbrush refused to do
what was needed, I would then go get another one.

It is partially a matter of personal pride, and having a desire for the artist to be
master over his tools, rather than the other way around.

Also, KISS comes to mind. I don't like digging for problems, and debugging a cmake script
instead of a Cmake statement is harder.