[CMake] Linking twice for CRC32

[Vincent van Beveren]

Hello  everyone,

For integrating the CRC to an ELF I believe I will need to link twice. 
First to create a binary on which to caclulate the CRC, and using a 
second pass to actually put the CRC into a the symbol at the last part 
of the RAM. Using the pointers by Eric  Noulard I have constructed the 
following CMake code, which links the file, exports a binary BIN file 
(the actual ROM image, and then calculates the CRC into a file called 
$.crc32.


# Exprimental CRC32 support
add_library(clb_v2_dom.objs OBJECT ${F_GEN} ${F__DOM})
target_compile_definitions(clb_v2_dom.objs PUBLIC -DDOM -DCLBV2 )
add_executable(clb_v2_dom.elf $)
add_custom_command(TARGET clb_v2_dom.elf POST_BUILD
    COMMAND ${CMAKE_OBJCOPY} $ ${SECTIONS} 
-O binary $.bin
    COMMAND ${Python_EXECUTABLE} ${CMAKE_SOURCE_DIR}/tools/crc32.py 
$.bin > $.crc32

)

with linker flags defined as

# Bring up the linker
add_link_options(
    -nostartfiles
    -nodefaultlibs
    -Wl,--gc-sections
    -nostdlib
    -T ${CMAKE_SOURCE_DIR}/${P_SRC}/romram.ld
    -Wl,--defsym=CRC_VALUE=0
    -Wl,--defsym=_start=0
    )

However, the last part is to link the file again with *exactly* the same 
invocation as the original linking, except for the 
'-Wl,--defsym=CRC_VALUE=<>' instead of 0.


Can anyone give me points on how to achieve this goal?

Kind regards,
Vincent

--
National Institute for Subatomic Physics Nikhef
Department of Computer Technology
Science Park 105
1098 XG AMSTERDAM

tel.  : +31 (0)20 592 2032
e-mail: v.van.beve...@nikhef.nl
site  : http://www.nikhef.nl/~vincentb

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

[Alan W. Irwin]

On 2019-10-10 18:21-0400 Paul Smith wrote:


On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote:

* The "UNITY_BUILD" target property was added to tell generators to
  batch include source files for faster compilation times.


Are there any instructions on how to make this work?  I tried this:

 cmake -G 'Unix Makefiles' -DCMAKE_UNITY_BUILD=ON .

Then ran "make".  The output showed I had just as many output .o files
as input .cpp files and that make ran one compile command per .cpp
file.

Is there something else I need to do to enable unity builds in my cmake
files, than just give the above option?  The docs imply that the above
is all that's needed.


Hi Paul:

I have never tried unity builds, but your question did inspire me to
look at [the unity build
documentation](https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html)
which if you follow the links to other related documentation does imply what
you have done above is correct and should by default group 8
source-code files into a lump to be compiled together.  Since you are
not getting that behaviour, I am wondering if one or more of the
documented reasons for skipping unity builds is making a difference in your
case. Those reasons are the following:

"The source files marked by GENERATED will be skipped from unity build. This 
applies also for the source files marked with SKIP_UNITY_BUILD_INCLUSION.

The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS, COMPILE_FLAGS, or 
INCLUDE_DIRECTORIES will also be skipped."

Good luck, and I hope you will keep the list informed of any further
progress you make with your unity build experiments.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Unity builds vs. compile_commands.json (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

[Paul Smith]

On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote:
> * The "UNITY_BUILD" target property was added to tell generators to
>   batch include source files for faster compilation times.

For some reason this didn't work with my actual cmake environment, but
I could enable it on a simple test environment.  I can look into that
later.

Here my concern is that you cannot use unity builds if you need
compile_commands.json (-DCMAKE_EXPORT_COMPILE_COMMANDS=ON); for example
if this is required by your IDE or other build tools.  When unity
builds are enabled the json file is not usable since it contains only
commands for the unity source files and doesn't describe the original
source files.

Is there an intent to address this before the 3.16 release?  

Or is this a known limitation, which may or may not be addressed in
some future version of CMake?

If the latter it should probably be added to the release notes and/or
documentation for unity builds.

Thanks!

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

[Paul Smith]

On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote:
> * The "UNITY_BUILD" target property was added to tell generators to
>   batch include source files for faster compilation times.

Are there any instructions on how to make this work?  I tried this:

  cmake -G 'Unix Makefiles' -DCMAKE_UNITY_BUILD=ON .

Then ran "make".  The output showed I had just as many output .o files
as input .cpp files and that make ran one compile command per .cpp
file.

Is there something else I need to do to enable unity builds in my cmake
files, than just give the above option?  The docs imply that the above
is all that's needed.

Cheers!

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing

[Robert Maynard via CMake]

I am proud to announce the first CMake 3.16 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.16

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.16/release/3.16.html

Some of the more significant changes in CMake 3.16 are:

* CMake learned to support the Objective C ("OBJC") and Objective
  C++ ("OBJCXX") languages.  They may be enabled via the "project()"
  and "enable_language()" commands.  When "OBJC" or "OBJCXX" is
  enabled, source files with the ".m" or ".mm", respectively, will be
  compiled as Objective C or C++.  Otherwise they will be treated as
  plain C++ sources as they were before.

* The "target_precompile_headers()" command was added to specify a
  list of headers to precompile for faster compilation times.

* The "UNITY_BUILD" target property was added to tell generators to
  batch include source files for faster compilation times.

* The "find_file()", "find_library()", "find_path()",
  "find_package()", and "find_program()" commands have learned to
  check the following variables to control searching

  * "CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH" - Controls the searching
the cmake-specific environment variables.

  * "CMAKE_FIND_USE_CMAKE_PATH" - Controls the searching the cmake-
specific cache variables.

  * "CMAKE_FIND_USE_CMAKE_SYSTEM_PATH" - Controls the searching
cmake platform specific variables.

  * "CMAKE_FIND_USE_PACKAGE_ROOT_PATH" - Controls the searching of
"_ROOT" variables.

  * "CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH" - Controls the
searching the standard system environment variables.

* The "file()" command learned a new sub-command,
  "GET_RUNTIME_DEPENDENCIES", which allows you to recursively get the
  list of libraries linked by an executable or library. This sub-
  command is intended as a replacement for "GetPrerequisites".

* "ctest(1)" now has the ability to serialize tests based on
  hardware requirements for each test. See Hardware Allocation for
  details.

* On AIX, executables using the "ENABLE_EXPORTS" target property now
  produce a linker import file with a ".imp" extension in addition to
  the executable file.  Plugins (created via "add_library()" with the
  "MODULE" option) that use "target_link_libraries()" to link to the
  executable for its symbols are now linked using the import file. The
  "install(TARGETS)" command now installs the import file as an
  "ARCHIVE" artifact.

* On AIX, runtime linking is no longer enabled by default.  CMake
  provides the linker enough information to resolve all symbols up
  front. One may manually enable runtime linking for shared libraries
  and/or loadable modules by adding "-Wl,-G" to their link flags (e.g.
  in the "CMAKE_SHARED_LINKER_FLAGS" or "CMAKE_MODULE_LINKER_FLAGS"
  variable). One may manually enable runtime linking for executables
  by adding "-Wl,-brtl" to their link flags (e.g. in the
  "CMAKE_EXE_LINKER_FLAGS" variable).

* "cmake(1)" "-E" now supports "true" and "false" commands, which do
  nothing while returning exit codes of 0 and 1, respectively.

* "cmake(1)" gained a "--trace-redirect=" command line option
  that can be used to redirect "--trace" output to a file instead of
  "stderr".

* The "cmake(1)" "--loglevel" command line option has been renamed
  to "--log-level" to make it consistent with the naming of other
  command line options.  The "--loglevel" option is still supported to
  preserve backward compatibility.

* The "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" variable has been
  deprecated.  Use the "CMAKE_FIND_USE_PACKAGE_REGISTRY" variable
  instead.

* The "GetPrerequisites" module has been deprecated, as it has been
  superceded by "file(GET_RUNTIME_DEPENDENCIES)".


CMake 3.16 Release Notes


Changes made since CMake 3.15 include the following.


New Features



Languages
-

* CMake learned to support the Objective C ("OBJC") and Objective
  C++ ("OBJCXX") languages.  They may be enabled via the "project()"
  and "enable_language()" commands.  When "OBJC" or "OBJCXX" is
  enabled, source files with the ".m" or ".mm", respectively, will be
  compiled as Objective C or C++.  Otherwise they will be treated as
  plain C++ sources as they were before.


Compilers
-

* The "Clang" compiler is now supported on "Solaris".


Platforms
-

* On AIX, executables using the "ENABLE_EXPORTS" target property now
  produce a linker import file with a ".imp" extension in addition to
  the executable file.  Plugins (created via "add_library()" with the
  "MODULE" option) that use "target_link_libraries()" to link to the
  executable for its symbols are now linked using the import file. The
  "install(TARGETS)" command now installs the import file as an
  "ARCHIVE" artifact.

* On AIX, runtime linking is no longer enabled by default.  CMake
  provides the linker enough information to resolve all symbols up
  front. One m

Re: [CMake] cmake end user vs. developer rpath handling

[DIXON, MARK C.]

On Thu, 10 Oct 2019, Eric Noulard wrote:
...
> with patchelf is works with an intriguing warning:
> warning: working around a Linux kernel bug by creating a hole of 2093056
> bytes in ‘/path/to/executable’
>
> which seems to be a resolved issue:
> https://github.com/NixOS/patchelf/issues/92
>
> after that on the modified executable,
> chrpath is printing weird output when asking to read rpath.
> patchelf does properly print modified rpath.
>
> I think the SO article gives enough reference for this:
> https://stackoverflow.com/questions/13769141/can-i-change-rpath-in-an-already-compiled-binary
>
> So I was wrong, thank you for your honest question Jakub.
> I learned something usefull thanks to you.
...

Thanks both! Great news - being unable to grow rpath was always really 
irritating.

Mark
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake end user vs. developer rpath handling

[DIXON, MARK C.]

On Thu, 10 Oct 2019, Eric Noulard wrote:
...
> No rpath and using "only" LD_LIBRARY_PATH is not feasible in that case?
> Removing rpath is easy; chrpath -d lib_or_exe

You could but, to avoid a maintenance headache, you'd normally end up 
getting the environment module to load any prereq environment modules, 
which would modify LD_LIBRARY_PATH.

In either case, it'd mean unexpectedly polluting the user's environment 
with things they didn't explicitly ask for, which I don't like doing.

...
> Or may be  commenting it out and specify CMAKE_INSTALL_RPATH on the command
> line:
>
> cmake
> -DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath
> 
...

Sorry - yes, I'm commenting it out and then specifying the 
CMAKE_INSTALL_RPATH I want on the command line.

Best,

Mark
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] HOWTO declare component inter-dependencies in multi-component packages

[stefan]

ping ?

On 2019-10-07 12:47 p.m., stefan wrote:


Hi,

can you reproduce my observations ? I'm I doing something wrong or is 
there indeed an issue with CMake ? Should I follow up with a bug report ?


Thanks,

On 2019-10-04 2:20 p.m., stefan wrote:



On 2019-10-03 5:24 p.m., Kyle Edwards wrote:

On Thu, 2019-10-03 at 17:08 -0400, stefan wrote:

Yes, that is exactly what I'm trying to do, but it doesn't seem to
have any effect. That is, `dpkg --info ...` doesn't list the
additional dependency, and correspondingly, running `apt-get install
...` on the component package file will install the package without
first installing the prerequisite component.
Consider this declaration:
   set(CPACK_COMPONENTS_ALL runtime development mstool)
If I now write
   set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS runtime)
I will see no effect. That is, the "development" package still does
not depend on the "runtime" package.
So I try this:
   set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS RUNTIME)
in case capitalization is required. Now the "runtime" component seems
to get packaged twice (as per the cmake logs), but still no correct
dependencies.
Is it time for a bug report ?

Please send us a minimal CMakeLists.txt that reproduces the issue.


Sure. Here it is. The relevant line part is line 5. Please let me 
know what I'm doing wrong.


Thanks,

Stefan
--

   ...ich hab' noch einen Koffer in Berlin...
 


Stefan
--

   ...ich hab' noch einen Koffer in Berlin...
 


Stefan

--

  ...ich hab' noch einen Koffer in Berlin...


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake end user vs. developer rpath handling

[Zakrzewski, Jakub]

From: Eric Noulard 
Sent: 10 October 2019 14:43
To: Zakrzewski, Jakub
Cc: cmake@cmake.org
Subject: Re: [CMake] cmake end user vs. developer rpath handling


> So I was wrong, thank you for your honest question Jakub.
> I learned something usefull thanks to you.


?No problem, thanks for trying out.
I'd like to think that asking and answering questions (even the seemingly 
stupid ones) makes us learn new things.

--
Have a nice one,
Jakub
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake end user vs. developer rpath handling

[Eric Noulard]

Le jeu. 10 oct. 2019 à 14:30, Eric Noulard  a
écrit :

>
>
> Le jeu. 10 oct. 2019 à 14:02, Zakrzewski, Jakub <
> jakub.zakrzew...@scheer-group.com> a écrit :
>
>> --
>> *From:* CMake  on behalf of Eric Noulard <
>> eric.noul...@gmail.com>
>> *Sent:* 10 October 2019 12:05
>> *To:* DIXON, MARK C.
>> *Cc:* cmake@cmake.org
>> *Subject:* [DKIM] Re: [CMake] cmake end user vs. developer rpath handling
>>
>>
>> > No they can't because the maximum size is burried into the binary ELF
>> file,
>> > that why CMake "reserve" some space with many ";;;" in order to replace
>> BUILD_RPATH with INSTALL_RPATH when doing
>> > 'install'.
>>
>> Interesting.
>> So you're saying that this:
>> https://github.com/NixOS/patchelf/blob/8cc2d6b0946abb0009058865cd46165b69c4/src/patchelf.cc#L1288-L1319
>> does not really work? (An honest question)
>>
>
> Nope I meant that my manual page forr chrpath says:
>-r  | --replace 
>   Replace current rpath or runpath setting with the path
> given.  The new path must be shorter or the same length as the current path.
>
> patchelf does not seem to have this limitation.
> I remember trying and being hit by that issue, but I did not tried it
> recently.
> I'll try again and come back to you.
>

with chrpath try to replace an rpath with a longer one I get:
new rpath '/../lib:/purposely/too/long/rpath/hdsjds/dshkjhdsk/dsgdjsj' too
large; maximum length 104

with patchelf is works with an intriguing warning:
warning: working around a Linux kernel bug by creating a hole of 2093056
bytes in ‘/path/to/executable’

which seems to be a resolved issue:
https://github.com/NixOS/patchelf/issues/92

after that on the modified executable,
chrpath is printing weird output when asking to read rpath.
patchelf does properly print modified rpath.

I think the SO article gives enough reference for this:
https://stackoverflow.com/questions/13769141/can-i-change-rpath-in-an-already-compiled-binary

So I was wrong, thank you for your honest question Jakub.
I learned something usefull thanks to you.


-- 
Eric
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake end user vs. developer rpath handling

[Eric Noulard]

Le jeu. 10 oct. 2019 à 14:02, Zakrzewski, Jakub <
jakub.zakrzew...@scheer-group.com> a écrit :

> --
> *From:* CMake  on behalf of Eric Noulard <
> eric.noul...@gmail.com>
> *Sent:* 10 October 2019 12:05
> *To:* DIXON, MARK C.
> *Cc:* cmake@cmake.org
> *Subject:* [DKIM] Re: [CMake] cmake end user vs. developer rpath handling
>
>
> > No they can't because the maximum size is burried into the binary ELF
> file,
> > that why CMake "reserve" some space with many ";;;" in order to replace
> BUILD_RPATH with INSTALL_RPATH when doing
> > 'install'.
>
> Interesting.
> So you're saying that this:
> https://github.com/NixOS/patchelf/blob/8cc2d6b0946abb0009058865cd46165b69c4/src/patchelf.cc#L1288-L1319
> does not really work? (An honest question)
>

Nope I meant that my manual page forr chrpath says:
   -r  | --replace 
  Replace current rpath or runpath setting with the path
given.  The new path must be shorter or the same length as the current path.

patchelf does not seem to have this limitation.
I remember trying and being hit by that issue, but I did not tried it
recently.
I'll try again and come back to you.

-- 
Eric
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake end user vs. developer rpath handling

[Zakrzewski, Jakub]

From: CMake  on behalf of Eric Noulard 

Sent: 10 October 2019 12:05
To: DIXON, MARK C.
Cc: cmake@cmake.org
Subject: [DKIM] Re: [CMake] cm?ake end user vs. developer rpath handling


> No they can't because the maximum size is burried into the binary ELF file,
> that why CMake "reserve" some space with many ";;;" in order to replace 
> BUILD_RPATH with INSTALL_RPATH when doing
> 'install'.

Interesting.
So you're saying that this: 
https://github.com/NixOS/patchelf/blob/8cc2d6b0946abb0009058865cd46165b69c4/src/patchelf.cc#L1288-L1319?
does not really work? (An honest question)

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake end user vs. developer rpath handling

[Eric Noulard]

Le jeu. 10 oct. 2019 à 13:08, DIXON, MARK C.  a
écrit :

> On Thu, 10 Oct 2019, Eric Noulard wrote:
> ...
> > No they can't because the maximum size is burried into the binary ELF
> file,
> > that why CMake "reserve" some space with many ";;;" in order to replace
> > BUILD_RPATH with INSTALL_RPATH when doing
> > 'install'.
>
> Hi Eric,
>
> Interesting - any ideas on how big the padding is?
>


Not sure, but I bet CMake is reserving as much space as needed for the
forthcoming INSTALL_RPATH
(as opposed to BUILD_RPATH) he knows when specified in the CMakeLists.txt
I you rebuild the concerned from source try configuring it with a stupidly
long CMAKE_INSTALL_RPATH
i.e.

cmake
-DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath


Then, you can surely have a look using  chrpath -l lib_or_exe.


> > Note however that you should be able to "delete" RPATH: chrpath -d
> > and then rely on LD_LIBRARY_PATH, ld.so.config, etc
> >
> > The thing I don't quite understand why you need to replace/amend RPATH.
> In
> > my (very personal) use case when I have to integrate third-party
> software:
>
> My use case is where:
>
> - I install some software, made available to others via environment
>modules (http://modules.sourceforge.net/).
>
> - The installed software is dynamically linked to other libraries, also
>installed via environment modules.
>
> - I don't want to make people load modules for prerequisite libraries
>(and prerequisites for the prerequisites...) to use the software.
>


ok I see, I did use modules a long time ago on some now oldish supercomputer
in order to play with various compilers of library versions.


>
> A complication is that I end up having to build lots of copies of the same
> software but built with different prerequisites... so it has to be
> automated on top of the upstream project's build system.
>
> For applications using libraries, I've tended to use wrapper scripts as it
> means fewer arguments with build systems. But for libraries using
> libraries, rpath's the only real option.
>

No rpath and using "only" LD_LIBRARY_PATH is not feasible in that case?
Removing rpath is easy; chrpath -d lib_or_exe


> My rpath can get quite long.
>

Yes now I see why, depending on the number of  prerequisite you have and
how many
modules are loaded.


> ...
> > If the developers of the software you are using have chosen in their
> CMake
> > build-system to define an install RPATH your only safe bet
> > is probably to build & install the software at your favorite location or
> > propose an upstream patch for supporting unspecified RPATH.
> >
> > But may be I miss something in your use case?
>
> I guess I should be proposing upstream patches but, there are so many
> software projects to do this for, it has always been simpler to carry
> forward a small patch or patches. Perhaps I should be a better citizen.
>

It may not be tractable to file dozen of upstream patch and wait for
feedback
but in the case the build system does not offer a way to chose install
rpath content I think you are stucked
(beside remove rpath).


In this case, what feels easiest is to keep a patch commenting out the
> developer's RPATH definition in CMakeLists.txt, identified by Jakub
> earlier.
>

Yes I agree. However I my hypothesis of space reservation in RPATH by cmake
is write
you may want to replace with something that fits your needs and not simply
commenting it out.
Or may be  commenting it out and specify CMAKE_INSTALL_RPATH on the command
line:

cmake
-DCMAKE_INSTALL_RPATH=/as/log/as/you/want/path/in/order/to/safely/patch/rpath

https://cmake.org/cmake/help/v3.15/variable/CMAKE_INSTALL_RPATH.html

-- 
Eric
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake end user vs. developer rpath handling

[DIXON, MARK C.]

On Thu, 10 Oct 2019, Eric Noulard wrote:
...
> No they can't because the maximum size is burried into the binary ELF file,
> that why CMake "reserve" some space with many ";;;" in order to replace
> BUILD_RPATH with INSTALL_RPATH when doing
> 'install'.

Hi Eric,

Interesting - any ideas on how big the padding is?


> Note however that you should be able to "delete" RPATH: chrpath -d
> and then rely on LD_LIBRARY_PATH, ld.so.config, etc
>
> The thing I don't quite understand why you need to replace/amend RPATH. In
> my (very personal) use case when I have to integrate third-party software:

My use case is where:

- I install some software, made available to others via environment
   modules (http://modules.sourceforge.net/).

- The installed software is dynamically linked to other libraries, also
   installed via environment modules.

- I don't want to make people load modules for prerequisite libraries
   (and prerequisites for the prerequisites...) to use the software.

A complication is that I end up having to build lots of copies of the same 
software but built with different prerequisites... so it has to be 
automated on top of the upstream project's build system.

For applications using libraries, I've tended to use wrapper scripts as it 
means fewer arguments with build systems. But for libraries using 
libraries, rpath's the only real option.

My rpath can get quite long.


...
> If the developers of the software you are using have chosen in their CMake
> build-system to define an install RPATH your only safe bet
> is probably to build & install the software at your favorite location or
> propose an upstream patch for supporting unspecified RPATH.
>
> But may be I miss something in your use case?

I guess I should be proposing upstream patches but, there are so many 
software projects to do this for, it has always been simpler to carry 
forward a small patch or patches. Perhaps I should be a better citizen.

In this case, what feels easiest is to keep a patch commenting out the 
developer's RPATH definition in CMakeLists.txt, identified by Jakub 
earlier.

Cheers,

Mark
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] lintian errors when using cpack

[Gillman, Matthew]

Hi again

I just tried adding those additional two options, but I am getting the same 
error with lintian.

Is there something wrong in my shlibs or control file?

Thanks

Matthew

From: CMake  on behalf of "Gillman, Matthew" 

Date: Thursday, 10 October 2019 at 10:58
To: Kerstin Keller , "cmake@cmake.org" 

Subject: Re: [CMake] lintian errors when using cpack

Hi Kerstin

Sorry, I forgot to list them. Right now I only have the following set:

SET(CPACK_GENERATOR "DEB")
SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Me mailto:m...@me.com>>")
INCLUDE(CPack)

I will try adding the two you suggest and see how it goes, but I wouldn’t be 
surprised if there were others I need too.

I’ve had a look and I can’t see a file called `postint`.

Thanks for your help

Matthew


From: CMake  on behalf of Kerstin Keller 

Date: Thursday, 10 October 2019 at 10:49
To: "cmake@cmake.org" 
Subject: Re: [CMake] lintian errors when using cpack

Hi,

what CPACK_DEBIAN_* options have you set and to what values have you set them?
I guess you're both using:
set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)
set(CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS ON)

When I generate the file for my lib it looks a bit different (e.g. it pins the 
package to a certain version, but not sure if it is required, and I have never 
run the linter on the package):

libfoo 5 foo (= 5.4.0-1)

Also, does CMake generate the `postinst` control file for you? That one should 
trigger the ldconfig execution, but maybe something is not correct there? How 
do other packages trigger the ldconfig execution?

Best,
Kerstin
[Image removed by sender.]

Am Do., 10. Okt. 2019 um 10:16 Uhr schrieb Gillman, Matthew 
mailto:m.gill...@ucl.ac.uk>>:
It's great that cpack can generate different packages - in my case, a .deb file 
for Debian.

But if you then want to submit the generated .deb file to be part of Debian's 
official release, you have to run the lintian tool, and make sure you pass its 
checks. I have managed manually to fix some errors in the .deb file (which 
underneath is just an ar archive), and doubtless other warn ins and errors 
could be solved using appropriate CPACK_DEBIAN_* options in the CMakeLists.txt 
file. But I have a couple of errors which I don't know how to fix:

E: libsopt3.0: shlib-missing-in-control-file libsopt 3.0 for 
usr/lib/libsopt.so.3.0.1
E: libsopt3.0: package-must-activate-ldconfig-trigger usr/lib/libsopt.so.3.0.1

Probably the shilbs file and control file need correcting, but I can't find 
anything which makes sense to me. Here is the shills file:

libsopt 3 libsopt3.0

And here is the relevant section of the control file:

Package: libsopt3.0
Priority: optional
#Section: devel
Section: libs
#Version: 0.1.1
Version: 3.0

If anyone can help, I would be very grateful. Are there perhaps CPACK_DEBIAN_* 
options I could use to solve these issues?

Thanks

Matthew


--

Powered by 
www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: 
http://cmake.org/cmake/help/support.html
CMake Consulting: 
http://cmake.org/cmake/help/consulting.html
CMake Training Courses: 
http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Re: [CMake] lintian errors when using cpack

[Eric Noulard]

Le jeu. 10 oct. 2019 à 11:58, Gillman, Matthew  a
écrit :

> Hi Kerstin
>
>
>
> Sorry, I forgot to list them. Right now I only have the following set:
>
>
>
> SET(CPACK_GENERATOR "DEB")
>
> SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Me ")
>
> INCLUDE(CPack)
>
>
>
> I will try adding the two you suggest and see how it goes, but I wouldn’t
> be surprised if there were others I need too.
>

You may review CPack Deb feature in the documentation as well:
https://cmake.org/cmake/help/v3.15/cpack_gen/deb.html

I’ve had a look and I can’t see a file called `postint`.
>
>
>
> Thanks for your help
>
>
>
> Matthew
>


-- 
Eric
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake end user vs. developer rpath handling

[Eric Noulard]

Le jeu. 10 oct. 2019 à 10:36, DIXON, MARK C.  a
écrit :

> On Wed, 9 Oct 2019, Aaron Cohen wrote:
>
> > Is it not feasible to just let the build system do whatever it is going
> to
> > and use "chrpath" or "patchelf" to change the rpath after-the-fact?
>
> Thanks for the suggestion, but I need to add directories to the rpath: I
> believe that neither utility allows it to increase in size.
>


No they can't because the maximum size is burried into the binary ELF file,
that why CMake "reserve" some space with many ";;;" in order to replace
BUILD_RPATH with INSTALL_RPATH when doing
'install'.

Note however that you should be able to "delete" RPATH: chrpath -d
and then rely on LD_LIBRARY_PATH, ld.so.config, etc

The thing I don't quite understand why you need to replace/amend RPATH. In
my (very personal) use case when I have to integrate third-party software:

1a) I compile them from source and install them using the install prefix *I
need*. For cmake enabled build
 the RPATH will be updated with the one I need *during install*

2a) I use relocatable binary package (of any kind rpm, deb, or even tar.gz)
for which I know that RPATH are
  relative which can adapt to the location where I put them.
  If I cannot find a relocatable binary package then I go back to 1a).

As noted by Hendrik not every software developer are aware of the need for
relocation so they may bury non-relocatable rpath in their buildsystem.

Note that there is usually 2 options for CMake buildsystem and install
RPATH.
You can either:
 1. set some install RPATH (preferably in a relocatable way using $ORIGIN)
 2. don't specify install RPATH at all and let the final user/integrator
setup LD_LIBRARY_PATH or ld.so.config etc...

This is quite well summarized here:
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling

If the developers of the software you are using have chosen in their CMake
build-system to define an install RPATH your only safe bet
is probably to build & install the software at your favorite location or
propose an upstream patch for supporting unspecified RPATH.

But may be I miss something in your use case?

-- 
Eric
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] lintian errors when using cpack

[Gillman, Matthew]

Hi Kerstin

Sorry, I forgot to list them. Right now I only have the following set:

SET(CPACK_GENERATOR "DEB")
SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Me mailto:m...@me.com>>")
INCLUDE(CPack)

I will try adding the two you suggest and see how it goes, but I wouldn’t be 
surprised if there were others I need too.

I’ve had a look and I can’t see a file called `postint`.

Thanks for your help

Matthew


From: CMake  on behalf of Kerstin Keller 

Date: Thursday, 10 October 2019 at 10:49
To: "cmake@cmake.org" 
Subject: Re: [CMake] lintian errors when using cpack

Hi,

what CPACK_DEBIAN_* options have you set and to what values have you set them?
I guess you're both using:
set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)
set(CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS ON)

When I generate the file for my lib it looks a bit different (e.g. it pins the 
package to a certain version, but not sure if it is required, and I have never 
run the linter on the package):

libfoo 5 foo (= 5.4.0-1)

Also, does CMake generate the `postinst` control file for you? That one should 
trigger the ldconfig execution, but maybe something is not correct there? How 
do other packages trigger the ldconfig execution?

Best,
Kerstin
[Image removed by sender.]

Am Do., 10. Okt. 2019 um 10:16 Uhr schrieb Gillman, Matthew 
mailto:m.gill...@ucl.ac.uk>>:
It's great that cpack can generate different packages - in my case, a .deb file 
for Debian.

But if you then want to submit the generated .deb file to be part of Debian's 
official release, you have to run the lintian tool, and make sure you pass its 
checks. I have managed manually to fix some errors in the .deb file (which 
underneath is just an ar archive), and doubtless other warn ins and errors 
could be solved using appropriate CPACK_DEBIAN_* options in the CMakeLists.txt 
file. But I have a couple of errors which I don't know how to fix:

E: libsopt3.0: shlib-missing-in-control-file libsopt 3.0 for 
usr/lib/libsopt.so.3.0.1
E: libsopt3.0: package-must-activate-ldconfig-trigger usr/lib/libsopt.so.3.0.1

Probably the shilbs file and control file need correcting, but I can't find 
anything which makes sense to me. Here is the shills file:

libsopt 3 libsopt3.0

And here is the relevant section of the control file:

Package: libsopt3.0
Priority: optional
#Section: devel
Section: libs
#Version: 0.1.1
Version: 3.0

If anyone can help, I would be very grateful. Are there perhaps CPACK_DEBIAN_* 
options I could use to solve these issues?

Thanks

Matthew


--

Powered by 
www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: 
http://cmake.org/cmake/help/support.html
CMake Consulting: 
http://cmake.org/cmake/help/consulting.html
CMake Training Courses: 
http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] lintian errors when using cpack

[Kerstin Keller]

Hi,

what CPACK_DEBIAN_* options have you set and to what values have you set
them?

I guess you're both using:
set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)
set(CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS ON)

When I generate the file for my lib it looks a bit different (e.g. it pins
the package to a certain version, but not sure if it is required, and I
have never run the linter on the package):

libfoo 5 foo (= 5.4.0-1)

Also, does CMake generate the `postinst` control file for you? That one
should trigger the ldconfig execution, but maybe something is not correct
there? How do other packages trigger the ldconfig execution?

Best,
Kerstin

Am Do., 10. Okt. 2019 um 10:16 Uhr schrieb Gillman, Matthew <
m.gill...@ucl.ac.uk>:

> It's great that cpack can generate different packages - in my case, a .deb
> file for Debian.
>
> But if you then want to submit the generated .deb file to be part of
> Debian's official release, you have to run the lintian tool, and make sure
> you pass its checks. I have managed manually to fix some errors in the .deb
> file (which underneath is just an ar archive), and doubtless other warn ins
> and errors could be solved using appropriate CPACK_DEBIAN_* options in the
> CMakeLists.txt file. But I have a couple of errors which I don't know how
> to fix:
>
> E: libsopt3.0: shlib-missing-in-control-file libsopt 3.0 for
> usr/lib/libsopt.so.3.0.1
> E: libsopt3.0: package-must-activate-ldconfig-trigger
> usr/lib/libsopt.so.3.0.1
>
> Probably the shilbs file and control file need correcting, but I can't
> find anything which makes sense to me. Here is the shills file:
>
> libsopt 3 libsopt3.0
>
> And here is the relevant section of the control file:
>
> Package: libsopt3.0
> Priority: optional
> #Section: devel
> Section: libs
> #Version: 0.1.1
> Version: 3.0
>
> If anyone can help, I would be very grateful. Are there perhaps
> CPACK_DEBIAN_* options I could use to solve these issues?
>
> Thanks
>
>
>
> Matthew
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake end user vs. developer rpath handling

[DIXON, MARK C.]

On Wed, 9 Oct 2019, Aaron Cohen wrote:

> Is it not feasible to just let the build system do whatever it is going to
> and use "chrpath" or "patchelf" to change the rpath after-the-fact?

Thanks for the suggestion, but I need to add directories to the rpath: I 
believe that neither utility allows it to increase in size.

:)

Mark
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] lintian errors when using cpack

[Gillman, Matthew]

It's great that cpack can generate different packages - in my case, a .deb file 
for Debian.

But if you then want to submit the generated .deb file to be part of Debian's 
official release, you have to run the lintian tool, and make sure you pass its 
checks. I have managed manually to fix some errors in the .deb file (which 
underneath is just an ar archive), and doubtless other warn ins and errors 
could be solved using appropriate CPACK_DEBIAN_* options in the CMakeLists.txt 
file. But I have a couple of errors which I don't know how to fix:

E: libsopt3.0: shlib-missing-in-control-file libsopt 3.0 for 
usr/lib/libsopt.so.3.0.1
E: libsopt3.0: package-must-activate-ldconfig-trigger usr/lib/libsopt.so.3.0.1

Probably the shilbs file and control file need correcting, but I can't find 
anything which makes sense to me. Here is the shills file:

libsopt 3 libsopt3.0

And here is the relevant section of the control file:

Package: libsopt3.0
Priority: optional
#Section: devel
Section: libs
#Version: 0.1.1
Version: 3.0

If anyone can help, I would be very grateful. Are there perhaps CPACK_DEBIAN_* 
options I could use to solve these issues?

Thanks

Matthew


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake