Re: [Kicad-developers] RPATH issue on _pcbnew.so

[Wayne Stambaugh]

hauptmech,

I tested this on windows and it doesn't seem to break anything that I
can see so I merged it.  Thank you for your contribution to KiCad.

Cheers,

Wayne

On 2/25/2018 8:49 PM, hauptmech wrote:
> 
> Attached
> 
> On 26/02/18 11:15, Wayne Stambaugh wrote:
>> hauptmech,
>>
>> Would you please attach this change as a committed patch when you get
>> a chance?  I want to test this on windows and linux and maybe we can
>> get one of our macos devs to test it there as well.  I would like to
>> work out any packaging issues as soon as possible to give our package
>> devs as much time as possible to work out any issue for the stable
>> release.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 02/24/2018 08:49 PM, hauptmech wrote:
>>> I don't have enough understanding of all the platforms to suggest a
>>> full patch. However the following works for me on linux (two targets,
>>> but shared object files so there should be no significant change in
>>> compile time)
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] RPATH issue on _pcbnew.so

[hauptmech]

Attached

On 26/02/18 11:15, Wayne Stambaugh wrote:

hauptmech,

Would you please attach this change as a committed patch when you get 
a chance?  I want to test this on windows and linux and maybe we can 
get one of our macos devs to test it there as well.  I would like to 
work out any packaging issues as soon as possible to give our package 
devs as much time as possible to work out any issue for the stable 
release.


Thanks,

Wayne

On 02/24/2018 08:49 PM, hauptmech wrote:
I don't have enough understanding of all the platforms to suggest a 
full patch. However the following works for me on linux (two targets, 
but shared object files so there should be no significant change in 
compile time)


>From 4aa94f47c48befee4c9bcd85c974b92a0b99dd4e Mon Sep 17 00:00:00 2001
From: hauptmech 
Date: Mon, 26 Feb 2018 14:36:12 +1300
Subject: [PATCH] Fix RPATH not removed in shared object file for python
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.16.2"

This is a multi-part message in MIME format.
--2.16.2
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit


Build pcbnew_kiface files as object target that can then be linked in to pcbnew.kiface and _pcbnew.so
Only create _pcbnew.so target if scripting modules is enabled.
For linux builds only.
---
 pcbnew/CMakeLists.txt | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)


--2.16.2
Content-Type: text/x-patch; name="0001-Fix-RPATH-not-removed-in-shared-object-file-for-pyth.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Fix-RPATH-not-removed-in-shared-object-file-for-pyth.patch"

diff --git a/pcbnew/CMakeLists.txt b/pcbnew/CMakeLists.txt
index 520dc1166..3ec6bbc23 100644
--- a/pcbnew/CMakeLists.txt
+++ b/pcbnew/CMakeLists.txt
@@ -608,12 +608,15 @@ if( PCBNEW_LINK_MAPS )
 endif()
 
 # the main pcbnew program, in DSO form.
-add_library( pcbnew_kiface MODULE
+add_library( pcbnew_kiface_objects OBJECT
 pcbnew.cpp
 ${PCBNEW_SRCS}
 ${PCBNEW_COMMON_SRCS}
 ${PCBNEW_SCRIPTING_SRCS}
 )
+
+add_library( pcbnew_kiface MODULE $ )
+
 set_target_properties( pcbnew_kiface PROPERTIES
 # Decorate OUTPUT_NAME with PREFIX and SUFFIX, creating something like
 # _pcbnew.so, _pcbnew.dll, or _pcbnew.kiface
@@ -640,7 +643,7 @@ if( ${OPENMP_FOUND} )
 )
 endif()
 
-target_link_libraries( pcbnew_kiface
+set( PCBNEW_KIFACE_LIBRARIES
 3d-viewer
 pcbcommon
 pnsrouter
@@ -660,6 +663,9 @@ target_link_libraries( pcbnew_kiface
 ${OPENMP_LIBRARIES}
 )
 
+
+target_link_libraries( pcbnew_kiface ${PCBNEW_KIFACE_LIBRARIES} )
+
 set_source_files_properties( pcbnew.cpp PROPERTIES
 # The KIFACE is in pcbnew.cpp, export it:
 COMPILE_DEFINITIONS "BUILD_KIWAY_DLL;COMPILING_DLL"
@@ -777,9 +783,12 @@ if( KICAD_SCRIPTING_MODULES )
 )
 add_dependencies( ScriptingModulesPcbnewSoCopy ScriptingWxpythonCopy )
 set( PYMOD_EXT "so" )
-
 else()  # only linux remains among supported platforms
-install( FILES ${CMAKE_BINARY_DIR}/pcbnew/_pcbnew.so DESTINATION ${PYTHON_DEST} )
+add_library( pcbnew_python MODULE $ )
+target_link_libraries( pcbnew_python ${PCBNEW_KIFACE_LIBRARIES} )
+set_target_properties( pcbnew_python PROPERTIES OUTPUT_NAME pcbnew PREFIX "_" SUFFIX ".so" )
+install( TARGETS pcbnew_python DESTINATION ${PYTHON_DEST} COMPONENT binary )
+
 set( PYMOD_EXT "so" )
 endif()
 

--2.16.2--


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] RPATH issue on _pcbnew.so

[Adam Wolf]

We can test it for macOS as well.  I'm spending some time on it every day
at this point to get it ready for v5, so now is the perfect time :)

On Feb 25, 2018 4:16 PM, "Wayne Stambaugh"  wrote:

> hauptmech,
>
> Would you please attach this change as a committed patch when you get a
> chance?  I want to test this on windows and linux and maybe we can get one
> of our macos devs to test it there as well.  I would like to work out any
> packaging issues as soon as possible to give our package devs as much time
> as possible to work out any issue for the stable release.
>
> Thanks,
>
> Wayne
>
> On 02/24/2018 08:49 PM, hauptmech wrote:
>
>> I don't have enough understanding of all the platforms to suggest a full
>> patch. However the following works for me on linux (two targets, but shared
>> object files so there should be no significant change in compile time)
>>
>> diff --git a/pcbnew/CMakeLists.txt b/pcbnew/CMakeLists.txt
>> index 520dc1166..78bd19cee 100644
>> --- a/pcbnew/CMakeLists.txt
>> +++ b/pcbnew/CMakeLists.txt
>> @@ -608,12 +608,14 @@ if( PCBNEW_LINK_MAPS )
>>   endif()
>>
>>   # the main pcbnew program, in DSO form.
>> -add_library( pcbnew_kiface MODULE
>> +add_library( pcbnew_kiface_objects OBJECT
>>   pcbnew.cpp
>>   ${PCBNEW_SRCS}
>>   ${PCBNEW_COMMON_SRCS}
>>   ${PCBNEW_SCRIPTING_SRCS}
>>   )
>> +add_library( pcbnew_kiface MODULE $
>> )
>> +
>>   set_target_properties( pcbnew_kiface PROPERTIES
>>   # Decorate OUTPUT_NAME with PREFIX and SUFFIX, creating something
>> like
>>   # _pcbnew.so, _pcbnew.dll, or _pcbnew.kiface
>> @@ -640,7 +642,7 @@ if( ${OPENMP_FOUND} )
>>   )
>>   endif()
>>
>> -target_link_libraries( pcbnew_kiface
>> +set( PCBNEW_KIFACE_LIBRARIES
>>   3d-viewer
>>   pcbcommon
>>   pnsrouter
>> @@ -660,6 +662,9 @@ target_link_libraries( pcbnew_kiface
>>   ${OPENMP_LIBRARIES}
>>   )
>>
>> +
>> +target_link_libraries( pcbnew_kiface ${PCBNEW_KIFACE_LIBRARIES})
>> +
>>   set_source_files_properties( pcbnew.cpp PROPERTIES
>>   # The KIFACE is in pcbnew.cpp, export it:
>>   COMPILE_DEFINITIONS "BUILD_KIWAY_DLL;COMPILING_DLL"
>> @@ -779,7 +784,11 @@ if( KICAD_SCRIPTING_MODULES )
>>   set( PYMOD_EXT "so" )
>>
>>   else()  # only linux remains among supported platforms
>> -install( FILES ${CMAKE_BINARY_DIR}/pcbnew/_pcbnew.so
>> DESTINATION ${PYTHON_DEST} )
>> +add_library( pcbnew_python MODULE 
>> $
>> )
>> +target_link_libraries( pcbnew_python ${PCBNEW_KIFACE_LIBRARIES})
>> +set_target_properties( pcbnew_python PROPERTIES OUTPUT_NAME
>> pcbnew PREFIX "_" SUFFIX ".so")
>> +install( TARGETS pcbnew_python DESTINATION ${PYTHON_DEST}
>> COMPONENT binary)
>> +
>>   set( PYMOD_EXT "so" )
>>   endif()
>>
>>
>>
>>
>> On Sun, Feb 25, 2018 at 2:42 PM, Cirilo Bernardo <
>> cirilo.berna...@gmail.com > wrote:
>>
>> What do you mean by a second target? Keep in mind that we don't want
>> to
>> recompile everything twice just because of the kiface libraries. If
>> you can
>> create a target which is dependent on the pcbnew stand-alone app and
>> which used the object files to create a shared library, that would
>> be good.
>> I can't recall offhand if some object files would need to be rebuilt
>> for
>> the kiface library, but that can be handled by CMake as well.
>>
>> Regarding  KiCad using pcbnew.kiface directly, I suspect the
>> intention was for
>> pcbnew to use that library regardless of whether it was run via the
>> KiCad
>> application or as the pcbnew standalone application. On that topic
>> I'd rather
>> do nothing until KiCad could be refactored to the point where a core
>> pcb API
>> is completely independent of the GUI; at the moment there is such a
>> tight
>> coupling between the GUI and operations on the PCB that it's
>> difficult to
>> see how some things work.
>>
>> Cirilo
>>
>> On Sun, Feb 25, 2018 at 1:20 AM, hauptmech > > wrote:
>>  > I took a look at what approaches might work to fix this.
>>  >
>>  > I looked at removing the RPATH manually, in keeping with manual
>> file
>>  > manipulation approach used by the authors of this section of the
>> CMake file.
>>  > Shell tools to do this don't appear to be universal and it's not
>> using the
>>  > CMake way. So I moved on.
>>  >
>>  > The approach that looks the most promising to me is to create a
>> second
>>  > target for the scripting library with the same sources as
>> pcbnew.kiface.
>>  > Then CMakes install Target will remove the RPATH as expected. To
>> reduce the
>>  > impact on compile time one could use:
>>  > https://cmake.org/Wiki/CMake/Tutorials/Object_Library
>> 
>>

Re: [Kicad-developers] RPATH issue on _pcbnew.so

[Wayne Stambaugh]

hauptmech,

Would you please attach this change as a committed patch when you get a 
chance?  I want to test this on windows and linux and maybe we can get 
one of our macos devs to test it there as well.  I would like to work 
out any packaging issues as soon as possible to give our package devs as 
much time as possible to work out any issue for the stable release.


Thanks,

Wayne

On 02/24/2018 08:49 PM, hauptmech wrote:
I don't have enough understanding of all the platforms to suggest a full 
patch. However the following works for me on linux (two targets, but 
shared object files so there should be no significant change in compile 
time)


diff --git a/pcbnew/CMakeLists.txt b/pcbnew/CMakeLists.txt
index 520dc1166..78bd19cee 100644
--- a/pcbnew/CMakeLists.txt
+++ b/pcbnew/CMakeLists.txt
@@ -608,12 +608,14 @@ if( PCBNEW_LINK_MAPS )
  endif()

  # the main pcbnew program, in DSO form.
-add_library( pcbnew_kiface MODULE
+add_library( pcbnew_kiface_objects OBJECT
  pcbnew.cpp
  ${PCBNEW_SRCS}
  ${PCBNEW_COMMON_SRCS}
  ${PCBNEW_SCRIPTING_SRCS}
  )
+add_library( pcbnew_kiface MODULE $ )
+
  set_target_properties( pcbnew_kiface PROPERTIES
  # Decorate OUTPUT_NAME with PREFIX and SUFFIX, creating something like
  # _pcbnew.so, _pcbnew.dll, or _pcbnew.kiface
@@ -640,7 +642,7 @@ if( ${OPENMP_FOUND} )
  )
  endif()

-target_link_libraries( pcbnew_kiface
+set( PCBNEW_KIFACE_LIBRARIES
  3d-viewer
  pcbcommon
  pnsrouter
@@ -660,6 +662,9 @@ target_link_libraries( pcbnew_kiface
  ${OPENMP_LIBRARIES}
  )

+
+target_link_libraries( pcbnew_kiface ${PCBNEW_KIFACE_LIBRARIES})
+
  set_source_files_properties( pcbnew.cpp PROPERTIES
  # The KIFACE is in pcbnew.cpp, export it:
  COMPILE_DEFINITIONS "BUILD_KIWAY_DLL;COMPILING_DLL"
@@ -779,7 +784,11 @@ if( KICAD_SCRIPTING_MODULES )
  set( PYMOD_EXT "so" )

  else()  # only linux remains among supported platforms
-    install( FILES ${CMAKE_BINARY_DIR}/pcbnew/_pcbnew.so 
DESTINATION ${PYTHON_DEST} )
+    add_library( pcbnew_python MODULE 
$ )

+    target_link_libraries( pcbnew_python ${PCBNEW_KIFACE_LIBRARIES})
+    set_target_properties( pcbnew_python PROPERTIES OUTPUT_NAME 
pcbnew PREFIX "_" SUFFIX ".so")
+    install( TARGETS pcbnew_python DESTINATION ${PYTHON_DEST} 
COMPONENT binary)

+
  set( PYMOD_EXT "so" )
  endif()




On Sun, Feb 25, 2018 at 2:42 PM, Cirilo Bernardo 
> wrote:


What do you mean by a second target? Keep in mind that we don't want to
recompile everything twice just because of the kiface libraries. If
you can
create a target which is dependent on the pcbnew stand-alone app and
which used the object files to create a shared library, that would
be good.
I can't recall offhand if some object files would need to be rebuilt for
the kiface library, but that can be handled by CMake as well.

Regarding  KiCad using pcbnew.kiface directly, I suspect the
intention was for
pcbnew to use that library regardless of whether it was run via the
KiCad
application or as the pcbnew standalone application. On that topic
I'd rather
do nothing until KiCad could be refactored to the point where a core
pcb API
is completely independent of the GUI; at the moment there is such a
tight
coupling between the GUI and operations on the PCB that it's
difficult to
see how some things work.

Cirilo

On Sun, Feb 25, 2018 at 1:20 AM, hauptmech > wrote:
 > I took a look at what approaches might work to fix this.
 >
 > I looked at removing the RPATH manually, in keeping with manual file
 > manipulation approach used by the authors of this section of the
CMake file.
 > Shell tools to do this don't appear to be universal and it's not
using the
 > CMake way. So I moved on.
 >
 > The approach that looks the most promising to me is to create a
second
 > target for the scripting library with the same sources as
pcbnew.kiface.
 > Then CMakes install Target will remove the RPATH as expected. To
reduce the
 > impact on compile time one could use:
 > https://cmake.org/Wiki/CMake/Tutorials/Object_Library

 >
 > In the CMake file, Dick Hollenbeck mentions a future plan to use the
 > pcbnew.kiface file directly. Not sure what was involved with that.
 >
 > On 25/02/18 10:37, Carsten Schoenert wrote:
 >>
 >> Hello Wayne,
 >>
 >> Am 24.02.18 um 21:44 schrieb Wayne Stambaugh:
 >>>
 >>> Carsten,
 >>>
 >>> On 02/24/2018 02:08 PM, Carsten Schoenert wrote:
 
  Hi,
 
  I guess it's not intended that the library / shared object
_pcbnew.so
  build in pcbnew/ set up a RPATH based on 

Re: [Kicad-developers] RPATH issue on _pcbnew.so

[hauptmech]

I don't have enough understanding of all the platforms to suggest a full
patch. However the following works for me on linux (two targets, but shared
object files so there should be no significant change in compile time)

diff --git a/pcbnew/CMakeLists.txt b/pcbnew/CMakeLists.txt
index 520dc1166..78bd19cee 100644
--- a/pcbnew/CMakeLists.txt
+++ b/pcbnew/CMakeLists.txt
@@ -608,12 +608,14 @@ if( PCBNEW_LINK_MAPS )
 endif()

 # the main pcbnew program, in DSO form.
-add_library( pcbnew_kiface MODULE
+add_library( pcbnew_kiface_objects OBJECT
 pcbnew.cpp
 ${PCBNEW_SRCS}
 ${PCBNEW_COMMON_SRCS}
 ${PCBNEW_SCRIPTING_SRCS}
 )
+add_library( pcbnew_kiface MODULE $ )
+
 set_target_properties( pcbnew_kiface PROPERTIES
 # Decorate OUTPUT_NAME with PREFIX and SUFFIX, creating something like
 # _pcbnew.so, _pcbnew.dll, or _pcbnew.kiface
@@ -640,7 +642,7 @@ if( ${OPENMP_FOUND} )
 )
 endif()

-target_link_libraries( pcbnew_kiface
+set( PCBNEW_KIFACE_LIBRARIES
 3d-viewer
 pcbcommon
 pnsrouter
@@ -660,6 +662,9 @@ target_link_libraries( pcbnew_kiface
 ${OPENMP_LIBRARIES}
 )

+
+target_link_libraries( pcbnew_kiface ${PCBNEW_KIFACE_LIBRARIES})
+
 set_source_files_properties( pcbnew.cpp PROPERTIES
 # The KIFACE is in pcbnew.cpp, export it:
 COMPILE_DEFINITIONS "BUILD_KIWAY_DLL;COMPILING_DLL"
@@ -779,7 +784,11 @@ if( KICAD_SCRIPTING_MODULES )
 set( PYMOD_EXT "so" )

 else()  # only linux remains among supported platforms
-install( FILES ${CMAKE_BINARY_DIR}/pcbnew/_pcbnew.so DESTINATION
${PYTHON_DEST} )
+add_library( pcbnew_python MODULE
$ )
+target_link_libraries( pcbnew_python ${PCBNEW_KIFACE_LIBRARIES})
+set_target_properties( pcbnew_python PROPERTIES OUTPUT_NAME pcbnew
PREFIX "_" SUFFIX ".so")
+install( TARGETS pcbnew_python DESTINATION ${PYTHON_DEST}
COMPONENT binary)
+
 set( PYMOD_EXT "so" )
 endif()




On Sun, Feb 25, 2018 at 2:42 PM, Cirilo Bernardo 
wrote:

> What do you mean by a second target? Keep in mind that we don't want to
> recompile everything twice just because of the kiface libraries. If you can
> create a target which is dependent on the pcbnew stand-alone app and
> which used the object files to create a shared library, that would be good.
> I can't recall offhand if some object files would need to be rebuilt for
> the kiface library, but that can be handled by CMake as well.
>
> Regarding  KiCad using pcbnew.kiface directly, I suspect the intention was
> for
> pcbnew to use that library regardless of whether it was run via the KiCad
> application or as the pcbnew standalone application. On that topic I'd
> rather
> do nothing until KiCad could be refactored to the point where a core pcb
> API
> is completely independent of the GUI; at the moment there is such a tight
> coupling between the GUI and operations on the PCB that it's difficult to
> see how some things work.
>
> Cirilo
>
> On Sun, Feb 25, 2018 at 1:20 AM, hauptmech  wrote:
> > I took a look at what approaches might work to fix this.
> >
> > I looked at removing the RPATH manually, in keeping with manual file
> > manipulation approach used by the authors of this section of the CMake
> file.
> > Shell tools to do this don't appear to be universal and it's not using
> the
> > CMake way. So I moved on.
> >
> > The approach that looks the most promising to me is to create a second
> > target for the scripting library with the same sources as pcbnew.kiface.
> > Then CMakes install Target will remove the RPATH as expected. To reduce
> the
> > impact on compile time one could use:
> > https://cmake.org/Wiki/CMake/Tutorials/Object_Library
> >
> > In the CMake file, Dick Hollenbeck mentions a future plan to use the
> > pcbnew.kiface file directly. Not sure what was involved with that.
> >
> > On 25/02/18 10:37, Carsten Schoenert wrote:
> >>
> >> Hello Wayne,
> >>
> >> Am 24.02.18 um 21:44 schrieb Wayne Stambaugh:
> >>>
> >>> Carsten,
> >>>
> >>> On 02/24/2018 02:08 PM, Carsten Schoenert wrote:
> 
>  Hi,
> 
>  I guess it's not intended that the library / shared object _pcbnew.so
>  build in pcbnew/ set up a RPATH based on the build directory?
> >>>
> >>> This is the kicad python scripting shared object which should get
> >>> installed in the correct python library path.  CMake installs it in the
> >>> correct place on both my Debian and Ubuntu builds so I don't understand
> >>> what the issue is here.
> >>
> >> the build and installation is just fine, the issue is that this file has
> >> a RUNPATH set to folder there it was compiled. It should have *no*
> >> RUNPATH.
> >>
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>

Re: [Kicad-developers] RPATH issue on _pcbnew.so

[Cirilo Bernardo]

What do you mean by a second target? Keep in mind that we don't want to
recompile everything twice just because of the kiface libraries. If you can
create a target which is dependent on the pcbnew stand-alone app and
which used the object files to create a shared library, that would be good.
I can't recall offhand if some object files would need to be rebuilt for
the kiface library, but that can be handled by CMake as well.

Regarding  KiCad using pcbnew.kiface directly, I suspect the intention was for
pcbnew to use that library regardless of whether it was run via the KiCad
application or as the pcbnew standalone application. On that topic I'd rather
do nothing until KiCad could be refactored to the point where a core pcb API
is completely independent of the GUI; at the moment there is such a tight
coupling between the GUI and operations on the PCB that it's difficult to
see how some things work.

Cirilo

On Sun, Feb 25, 2018 at 1:20 AM, hauptmech  wrote:
> I took a look at what approaches might work to fix this.
>
> I looked at removing the RPATH manually, in keeping with manual file
> manipulation approach used by the authors of this section of the CMake file.
> Shell tools to do this don't appear to be universal and it's not using the
> CMake way. So I moved on.
>
> The approach that looks the most promising to me is to create a second
> target for the scripting library with the same sources as pcbnew.kiface.
> Then CMakes install Target will remove the RPATH as expected. To reduce the
> impact on compile time one could use:
> https://cmake.org/Wiki/CMake/Tutorials/Object_Library
>
> In the CMake file, Dick Hollenbeck mentions a future plan to use the
> pcbnew.kiface file directly. Not sure what was involved with that.
>
> On 25/02/18 10:37, Carsten Schoenert wrote:
>>
>> Hello Wayne,
>>
>> Am 24.02.18 um 21:44 schrieb Wayne Stambaugh:
>>>
>>> Carsten,
>>>
>>> On 02/24/2018 02:08 PM, Carsten Schoenert wrote:

 Hi,

 I guess it's not intended that the library / shared object _pcbnew.so
 build in pcbnew/ set up a RPATH based on the build directory?
>>>
>>> This is the kicad python scripting shared object which should get
>>> installed in the correct python library path.  CMake installs it in the
>>> correct place on both my Debian and Ubuntu builds so I don't understand
>>> what the issue is here.
>>
>> the build and installation is just fine, the issue is that this file has
>> a RUNPATH set to folder there it was compiled. It should have *no*
>> RUNPATH.
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] RPATH issue on _pcbnew.so

[hauptmech]

I took a look at what approaches might work to fix this.

I looked at removing the RPATH manually, in keeping with manual file 
manipulation approach used by the authors of this section of the CMake 
file. Shell tools to do this don't appear to be universal and it's not 
using the CMake way. So I moved on.


The approach that looks the most promising to me is to create a second 
target for the scripting library with the same sources as pcbnew.kiface. 
Then CMakes install Target will remove the RPATH as expected. To reduce 
the impact on compile time one could use: 
https://cmake.org/Wiki/CMake/Tutorials/Object_Library


In the CMake file, Dick Hollenbeck mentions a future plan to use the 
pcbnew.kiface file directly. Not sure what was involved with that.


On 25/02/18 10:37, Carsten Schoenert wrote:

Hello Wayne,

Am 24.02.18 um 21:44 schrieb Wayne Stambaugh:

Carsten,

On 02/24/2018 02:08 PM, Carsten Schoenert wrote:

Hi,

I guess it's not intended that the library / shared object _pcbnew.so
build in pcbnew/ set up a RPATH based on the build directory?

This is the kicad python scripting shared object which should get
installed in the correct python library path.  CMake installs it in the
correct place on both my Debian and Ubuntu builds so I don't understand
what the issue is here.

the build and installation is just fine, the issue is that this file has
a RUNPATH set to folder there it was compiled. It should have *no* RUNPATH.




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] RPATH issue on _pcbnew.so

[hauptmech]

I've confirmed that there is a wrong RPATH in the install. The issue is 
in pcbnew/CMakeFiles.txt#if( KICAD_SCRIPTING_MODULES ).


Rather than using the CMake install target script, _pcbnew.so is getting 
copied manually and then installed as a file.


On 25/02/18 10:37, Carsten Schoenert wrote:

Hello Wayne,

Am 24.02.18 um 21:44 schrieb Wayne Stambaugh:

Carsten,

On 02/24/2018 02:08 PM, Carsten Schoenert wrote:

Hi,

I guess it's not intended that the library / shared object _pcbnew.so
build in pcbnew/ set up a RPATH based on the build directory?

This is the kicad python scripting shared object which should get
installed in the correct python library path.  CMake installs it in the
correct place on both my Debian and Ubuntu builds so I don't understand
what the issue is here.

the build and installation is just fine, the issue is that this file has
a RUNPATH set to folder there it was compiled. It should have *no* RUNPATH.


root@i5:/# ldd build/kicad-5.0.0~rc0+dfsg1/debian/build/pcbnew/_pcbnew.so | 
grep build
libkicad_3dsg.so.2.0.0 => 
/build/kicad-5.0.0~rc0+dfsg1/debian/build/3d-viewer/3d_cache/sg/libkicad_3dsg.so.2.0.0
 (0x7f8188148000)

This causes that lintian (a big QS tool for Debian packaging) is writing
a error out on this. This package wouldn't be accepted from the FTP
master if I'd do a upload to NEW. And I need to upload to NEW as the
package structure will change.

This is the build path not the install path.

Partially correct. :-)
In Debian the build folder is created by '/build/$PACKAGE_$VERSION', the
out of tree build is typically done within the folder debian/build so
the root for building all is

/build/kicad-5.0.0~rc0+dfsg1/debian/build/...

So yes, the the first line from my paste is the build path, the second
line is just the output of 'ldd' with a grepped 'build' as argument.
_pcbnew.so is looking for libkicad_3dsg.so.2.0.0 in the path which is
shown there. And this is obviously wrong.


  By default on linux builds the shared object gets installed in
/usr/local/lib/libkicad_3dsg.so.2.0.0.  This is the 3D viewer plugin so
I don't know if this the correct convention for plugins but as it is a
shared object, it will get recognized by the os and load properly.  If
plugins should be installed in a different path, please let me know what
that path should be and we can change the cmake install path for this
shared object.

The installation of this private library is no problem, kicad does here
exactly what the standard folder is if the INSTALL_PATH isn't given. No
need something to change here.

...

I don't know what has to be changed here so I'd like to ask someone who
is more experienced with the cmake world.
I could change this with chrpath but it's better if upstream would fix
this. Surprisingly the library _pcbnew.kiface hasn't this issue so I'm a
bit clueless.

I don't know that anything changed that I am aware of with _pcbnew.so.
The 3D viewer plugin was introduced during this development cycle but I
have been successfully building and installing from source on Debian
during the entire current development cycle so I don't have any good
answers for you.

I have really no knowledge about cmake, but I can see some information
of setting the RUNPATH to an empty string while installing binaries or
shared objects in opposite of this Python library.


-- Installing: 
/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/share/kicad/scripting/kicad_pyshell/__init__.py
-- Installing: 
/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/python2.7/dist-packages/_pcbnew.so 
 <--- no modification here
-- Installing: /build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/bin/pl_editor
> -- Installing:

/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/bin/_pcb_calculator.kiface

-- Installing: 
/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_idf.so
-- Set runtime path of 
"/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_idf.so"
 to ""  <--
-- Installing: 
/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_vrml.so
-- Set runtime path of 
"/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_vrml.so"
 to ""  <--
-- Installing: 
/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_oce.so
-- Set runtime path of 
"/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_oce.so"
 to ""  <--

It's probably just a small thing that is needed to add $SOMETHERE to the
installation of this Python library.




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] RPATH issue on _pcbnew.so

[Cirilo Bernardo]

The RUNPATH should be stripped by the linker, if it isn't then there is a
problem in our build system. I created the various dynamic plugins and
the scenegraph library and made sure that the RUNPATH is removed;
it is of value primarily to developers and in general is nothing but a
headache when deploying software which is genuinely intended to
share libraries.

On Sat, Feb 24, 2018 at 9:37 PM, Carsten Schoenert
 wrote:
> Hello Wayne,
>
> Am 24.02.18 um 21:44 schrieb Wayne Stambaugh:
>> Carsten,
>>
>> On 02/24/2018 02:08 PM, Carsten Schoenert wrote:
>>> Hi,
>>>
>>> I guess it's not intended that the library / shared object _pcbnew.so
>>> build in pcbnew/ set up a RPATH based on the build directory?
>>
>> This is the kicad python scripting shared object which should get
>> installed in the correct python library path.  CMake installs it in the
>> correct place on both my Debian and Ubuntu builds so I don't understand
>> what the issue is here.
>
> the build and installation is just fine, the issue is that this file has
> a RUNPATH set to folder there it was compiled. It should have *no* RUNPATH.
>
 root@i5:/# ldd build/kicad-5.0.0~rc0+dfsg1/debian/build/pcbnew/_pcbnew.so 
 | grep build
 libkicad_3dsg.so.2.0.0 => 
 /build/kicad-5.0.0~rc0+dfsg1/debian/build/3d-viewer/3d_cache/sg/libkicad_3dsg.so.2.0.0
  (0x7f8188148000)
>>>
>>> This causes that lintian (a big QS tool for Debian packaging) is writing
>>> a error out on this. This package wouldn't be accepted from the FTP
>>> master if I'd do a upload to NEW. And I need to upload to NEW as the
>>> package structure will change.
>>
>> This is the build path not the install path.
>
> Partially correct. :-)
> In Debian the build folder is created by '/build/$PACKAGE_$VERSION', the
> out of tree build is typically done within the folder debian/build so
> the root for building all is
>
>/build/kicad-5.0.0~rc0+dfsg1/debian/build/...
>
> So yes, the the first line from my paste is the build path, the second
> line is just the output of 'ldd' with a grepped 'build' as argument.
> _pcbnew.so is looking for libkicad_3dsg.so.2.0.0 in the path which is
> shown there. And this is obviously wrong.
>
>>  By default on linux builds the shared object gets installed in
>> /usr/local/lib/libkicad_3dsg.so.2.0.0.  This is the 3D viewer plugin so
>> I don't know if this the correct convention for plugins but as it is a
>> shared object, it will get recognized by the os and load properly.  If
>> plugins should be installed in a different path, please let me know what
>> that path should be and we can change the cmake install path for this
>> shared object.
>
> The installation of this private library is no problem, kicad does here
> exactly what the standard folder is if the INSTALL_PATH isn't given. No
> need something to change here.
>
> ...
>>> I don't know what has to be changed here so I'd like to ask someone who
>>> is more experienced with the cmake world.
>>> I could change this with chrpath but it's better if upstream would fix
>>> this. Surprisingly the library _pcbnew.kiface hasn't this issue so I'm a
>>> bit clueless.
>>
>> I don't know that anything changed that I am aware of with _pcbnew.so.
>> The 3D viewer plugin was introduced during this development cycle but I
>> have been successfully building and installing from source on Debian
>> during the entire current development cycle so I don't have any good
>> answers for you.
>
> I have really no knowledge about cmake, but I can see some information
> of setting the RUNPATH to an empty string while installing binaries or
> shared objects in opposite of this Python library.
>
>> -- Installing: 
>> /build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/share/kicad/scripting/kicad_pyshell/__init__.py
>> -- Installing: 
>> /build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/python2.7/dist-packages/_pcbnew.so
>>   <--- no modification here
>> -- Installing: /build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/bin/pl_editor
>> > -- Installing:
> /build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/bin/_pcb_calculator.kiface
>> -- Installing: 
>> /build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_idf.so
>> -- Set runtime path of 
>> "/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_idf.so"
>>  to ""  <--
>> -- Installing: 
>> /build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_vrml.so
>> -- Set runtime path of 
>> "/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_vrml.so"
>>  to ""  <--
>> -- Installing: 
>> /build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_oce.so
>> -- Set runtime path of 
>> "/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_oce.so"
>>  to ""  <--
>
> It's probably just a small thing that is 

Re: [Kicad-developers] RPATH issue on _pcbnew.so

[hauptmech]

On 25/02/18 10:37, Carsten Schoenert wrote:

the build and installation is just fine, the issue is that this file has
a RUNPATH set to folder there it was compiled. It should have*no*  RUNPATH.


I'm not understanding this thread 100% so apologies if this misses the 
point.


RPATH is set by default by CMake in the build folder and then the RPATH 
is removed by the CMake install script during installation.


The explanation is here: https://cmake.org/Wiki/CMake_RPATH_handling

If this is a source build and install, you need to be checking the rpath 
on the installed file, not the build directory file.


If this is a packaging toolset for debian, I'm unfamiliar, however it 
seems strange to run lintian on the build files instead of the installed 
(presumably installed on a chroot) files.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] RPATH issue on _pcbnew.so

[Carsten Schoenert]

Hello Wayne,

Am 24.02.18 um 21:44 schrieb Wayne Stambaugh:
> Carsten,
> 
> On 02/24/2018 02:08 PM, Carsten Schoenert wrote:
>> Hi,
>>
>> I guess it's not intended that the library / shared object _pcbnew.so
>> build in pcbnew/ set up a RPATH based on the build directory?
> 
> This is the kicad python scripting shared object which should get 
> installed in the correct python library path.  CMake installs it in the 
> correct place on both my Debian and Ubuntu builds so I don't understand 
> what the issue is here.

the build and installation is just fine, the issue is that this file has
a RUNPATH set to folder there it was compiled. It should have *no* RUNPATH.

>>> root@i5:/# ldd build/kicad-5.0.0~rc0+dfsg1/debian/build/pcbnew/_pcbnew.so | 
>>> grep build
>>> libkicad_3dsg.so.2.0.0 => 
>>> /build/kicad-5.0.0~rc0+dfsg1/debian/build/3d-viewer/3d_cache/sg/libkicad_3dsg.so.2.0.0
>>>  (0x7f8188148000)
>>
>> This causes that lintian (a big QS tool for Debian packaging) is writing
>> a error out on this. This package wouldn't be accepted from the FTP
>> master if I'd do a upload to NEW. And I need to upload to NEW as the
>> package structure will change.
> 
> This is the build path not the install path.

Partially correct. :-)
In Debian the build folder is created by '/build/$PACKAGE_$VERSION', the
out of tree build is typically done within the folder debian/build so
the root for building all is

   /build/kicad-5.0.0~rc0+dfsg1/debian/build/...

So yes, the the first line from my paste is the build path, the second
line is just the output of 'ldd' with a grepped 'build' as argument.
_pcbnew.so is looking for libkicad_3dsg.so.2.0.0 in the path which is
shown there. And this is obviously wrong.

>  By default on linux builds the shared object gets installed in 
> /usr/local/lib/libkicad_3dsg.so.2.0.0.  This is the 3D viewer plugin so 
> I don't know if this the correct convention for plugins but as it is a 
> shared object, it will get recognized by the os and load properly.  If 
> plugins should be installed in a different path, please let me know what 
> that path should be and we can change the cmake install path for this 
> shared object.

The installation of this private library is no problem, kicad does here
exactly what the standard folder is if the INSTALL_PATH isn't given. No
need something to change here.

...
>> I don't know what has to be changed here so I'd like to ask someone who
>> is more experienced with the cmake world.
>> I could change this with chrpath but it's better if upstream would fix
>> this. Surprisingly the library _pcbnew.kiface hasn't this issue so I'm a
>> bit clueless.
> 
> I don't know that anything changed that I am aware of with _pcbnew.so. 
> The 3D viewer plugin was introduced during this development cycle but I 
> have been successfully building and installing from source on Debian 
> during the entire current development cycle so I don't have any good 
> answers for you.

I have really no knowledge about cmake, but I can see some information
of setting the RUNPATH to an empty string while installing binaries or
shared objects in opposite of this Python library.

> -- Installing: 
> /build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/share/kicad/scripting/kicad_pyshell/__init__.py
> -- Installing: 
> /build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/python2.7/dist-packages/_pcbnew.so
>   <--- no modification here
> -- Installing: /build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/bin/pl_editor
> > -- Installing:
/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/bin/_pcb_calculator.kiface
> -- Installing: 
> /build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_idf.so
> -- Set runtime path of 
> "/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_idf.so"
>  to ""  <--
> -- Installing: 
> /build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_vrml.so
> -- Set runtime path of 
> "/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_vrml.so"
>  to ""  <--
> -- Installing: 
> /build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_oce.so
> -- Set runtime path of 
> "/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_oce.so"
>  to ""  <--

It's probably just a small thing that is needed to add $SOMETHERE to the
installation of this Python library.

-- 
Regards
Carsten Schoenert

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] RPATH issue on _pcbnew.so

[Wayne Stambaugh]

Carsten,

On 02/24/2018 02:08 PM, Carsten Schoenert wrote:

Hi,

I guess it's not intended that the library / shared object _pcbnew.so
build in pcbnew/ set up a RPATH based on the build directory?


This is the kicad python scripting shared object which should get 
installed in the correct python library path.  CMake installs it in the 
correct place on both my Debian and Ubuntu builds so I don't understand 
what the issue is here.





root@i5:/# ldd build/kicad-5.0.0~rc0+dfsg1/debian/build/pcbnew/_pcbnew.so | 
grep build
libkicad_3dsg.so.2.0.0 => 
/build/kicad-5.0.0~rc0+dfsg1/debian/build/3d-viewer/3d_cache/sg/libkicad_3dsg.so.2.0.0
 (0x7f8188148000)


This causes that lintian (a big QS tool for Debian packaging) is writing
a error out on this. This package wouldn't be accepted from the FTP
master if I'd do a upload to NEW. And I need to upload to NEW as the
package structure will change.


This is the build path not the install path.  By default on linux builds 
the shared object gets installed in 
/usr/local/lib/libkicad_3dsg.so.2.0.0.  This is the 3D viewer plugin so 
I don't know if this the correct convention for plugins but as it is a 
shared object, it will get recognized by the os and load properly.  If 
plugins should be installed in a different path, please let me know what 
that path should be and we can change the cmake install path for this 
shared object.





root@i5:/build/kicad-5.0.0~rc0+dfsg1# lintian -E
warning: the authors of lintian do not recommend running it with root 
privileges!
E: kicad: binary-or-shlib-defines-rpath 
usr/lib/python2.7/dist-packages/_pcbnew.x86_64-linux-gnu.so 
/build/kicad-5.0.0~rc0+dfsg1/debian/build/3d-viewer/3d_cache/sg



As visible this shared object is moved into
/usr/lib/python2.7/dist-packages/_pcbnew.x86_64-linux-gnu.so as an
Python module.

I don't know what has to be changed here so I'd like to ask someone who
is more experienced with the cmake world.
I could change this with chrpath but it's better if upstream would fix
this. Surprisingly the library _pcbnew.kiface hasn't this issue so I'm a
bit clueless.


I don't know that anything changed that I am aware of with _pcbnew.so. 
The 3D viewer plugin was introduced during this development cycle but I 
have been successfully building and installing from source on Debian 
during the entire current development cycle so I don't have any good 
answers for you.


Wayne



The Debian wiki has some extra information about the Rpath problematic.

https://wiki.debian.org/RpathIssue



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] RPATH issue on _pcbnew.so

[Carsten Schoenert]

Hi,

I guess it's not intended that the library / shared object _pcbnew.so
build in pcbnew/ set up a RPATH based on the build directory?

> root@i5:/# ldd build/kicad-5.0.0~rc0+dfsg1/debian/build/pcbnew/_pcbnew.so | 
> grep build
>   libkicad_3dsg.so.2.0.0 => 
> /build/kicad-5.0.0~rc0+dfsg1/debian/build/3d-viewer/3d_cache/sg/libkicad_3dsg.so.2.0.0
>  (0x7f8188148000)

This causes that lintian (a big QS tool for Debian packaging) is writing
a error out on this. This package wouldn't be accepted from the FTP
master if I'd do a upload to NEW. And I need to upload to NEW as the
package structure will change.

> root@i5:/build/kicad-5.0.0~rc0+dfsg1# lintian -E
> warning: the authors of lintian do not recommend running it with root 
> privileges!
> E: kicad: binary-or-shlib-defines-rpath 
> usr/lib/python2.7/dist-packages/_pcbnew.x86_64-linux-gnu.so 
> /build/kicad-5.0.0~rc0+dfsg1/debian/build/3d-viewer/3d_cache/sg


As visible this shared object is moved into
/usr/lib/python2.7/dist-packages/_pcbnew.x86_64-linux-gnu.so as an
Python module.

I don't know what has to be changed here so I'd like to ask someone who
is more experienced with the cmake world.
I could change this with chrpath but it's better if upstream would fix
this. Surprisingly the library _pcbnew.kiface hasn't this issue so I'm a
bit clueless.

The Debian wiki has some extra information about the Rpath problematic.

https://wiki.debian.org/RpathIssue

-- 
Regards
Carsten Schoenert

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp