CMake: using dlopen

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

CMake: using dlopen

Franck Houssen
Hello,

I have an executable that needs dlopen.

Googled this a bit: seems (surprisingly) there is no FindDLUtils ?!.. Correct ? If so, why is this ?
My understanding is that I need to go:
~BUILD> cmake -DCMAKE_LD_LIBS="-ldl -L/path/to/dl" ..
which is, basically, telling to CMake where dl is (although this is the job of a build system, no ?!)

Did I understand correctly ? Did I miss something ?

Franck

--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

J Decker
probably just need target_link_libraries( <target> dl ) 

On Sat, Jan 6, 2018 at 6:34 AM, Franck Houssen <[hidden email]> wrote:
Hello,

I have an executable that needs dlopen.

Googled this a bit: seems (surprisingly) there is no FindDLUtils ?!.. Correct ? If so, why is this ?
My understanding is that I need to go:
~BUILD> cmake -DCMAKE_LD_LIBS="-ldl -L/path/to/dl" ..
which is, basically, telling to CMake where dl is (although this is the job of a build system, no ?!)

Did I understand correctly ? Did I miss something ?

Franck

--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Rainer Poisel
Hi,

I would use ${CMAKE_DL_LIBS} in target_link_libraries:


Regards,
  Rainer


On Jan 6, 2018 16:19, "J Decker" <[hidden email]> wrote:
probably just need target_link_libraries( <target> dl ) 

On Sat, Jan 6, 2018 at 6:34 AM, Franck Houssen <[hidden email]> wrote:
Hello,

I have an executable that needs dlopen.

Googled this a bit: seems (surprisingly) there is no FindDLUtils ?!.. Correct ? If so, why is this ?
My understanding is that I need to go:
~BUILD> cmake -DCMAKE_LD_LIBS="-ldl -L/path/to/dl" ..
which is, basically, telling to CMake where dl is (although this is the job of a build system, no ?!)

Did I understand correctly ? Did I miss something ?

Franck

--

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



--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Franck Houssen
In reply to this post by J Decker


De: "J Decker" <[hidden email]>
À: "Franck Houssen" <[hidden email]>
Cc: "CMake Mail List" <[hidden email]>
Envoyé: Samedi 6 Janvier 2018 16:19:33
Objet: Re: [CMake] CMake: using dlopen

probably just need target_link_libraries( <target> dl ) 

But so, who defined the dl target ?


On Sat, Jan 6, 2018 at 6:34 AM, Franck Houssen <[hidden email]> wrote:
Hello,

I have an executable that needs dlopen.

Googled this a bit: seems (surprisingly) there is no FindDLUtils ?!.. Correct ? If so, why is this ?
My understanding is that I need to go:
~BUILD> cmake -DCMAKE_LD_LIBS="-ldl -L/path/to/dl" ..
which is, basically, telling to CMake where dl is (although this is the job of a build system, no ?!)

Did I understand correctly ? Did I miss something ?

Franck

--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Franck Houssen
In reply to this post by Rainer Poisel



De: "Rainer Poisel" <[hidden email]>
À: "J Decker" <[hidden email]>
Cc: "Franck Houssen" <[hidden email]>, [hidden email]
Envoyé: Samedi 6 Janvier 2018 17:30:53
Objet: Re: [CMake] CMake: using dlopen

Hi,

I would use ${CMAKE_DL_LIBS} in target_link_libraries:


But here again, who defined ${CMAKE_DL_LIBS}: I don't see it when I run "cmake -LA ."



Regards,
  Rainer


On Jan 6, 2018 16:19, "J Decker" <[hidden email]> wrote:
probably just need target_link_libraries( <target> dl ) 

On Sat, Jan 6, 2018 at 6:34 AM, Franck Houssen <[hidden email]> wrote:
Hello,

I have an executable that needs dlopen.

Googled this a bit: seems (surprisingly) there is no FindDLUtils ?!.. Correct ? If so, why is this ?
My understanding is that I need to go:
~BUILD> cmake -DCMAKE_LD_LIBS="-ldl -L/path/to/dl" ..
which is, basically, telling to CMake where dl is (although this is the job of a build system, no ?!)

Did I understand correctly ? Did I miss something ?

Franck

--

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




--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

J Decker
In reply to this post by Franck Houssen
CMake/shared/modules will define the CMAKE_DL_LIBS  which a very high percentage of the time will just be library 'dl' .  

Pretty much any man page on dlopen defines 'dl'


 Link with -ldl.  
specifying just the library name adds it as a -L<libname> option to be searched with standard library functions.

On Sat, Jan 6, 2018 at 8:41 AM, Franck Houssen <[hidden email]> wrote:


De: "J Decker" <[hidden email]>
À: "Franck Houssen" <[hidden email]>
Cc: "CMake Mail List" <[hidden email]>
Envoyé: Samedi 6 Janvier 2018 16:19:33
Objet: Re: [CMake] CMake: using dlopen

probably just need target_link_libraries( <target> dl ) 

But so, who defined the dl target ?


On Sat, Jan 6, 2018 at 6:34 AM, Franck Houssen <[hidden email]> wrote:
Hello,

I have an executable that needs dlopen.

Googled this a bit: seems (surprisingly) there is no FindDLUtils ?!.. Correct ? If so, why is this ?
My understanding is that I need to go:
~BUILD> cmake -DCMAKE_LD_LIBS="-ldl -L/path/to/dl" ..
which is, basically, telling to CMake where dl is (although this is the job of a build system, no ?!)

Did I understand correctly ? Did I miss something ?

Franck

--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Roger Leigh
On 06/01/18 17:01, J Decker wrote:
> CMake/shared/modules will define the CMAKE_DL_LIBS  which a very high
> percentage of the time will just be library 'dl' .
>
> Pretty much any man page on dlopen defines 'dl'

On Linux.  On MaxOSX and FreeBSD not at all, where the dl functions are
in libSystem and libc, respectively.  Using CMAKE_DL_LIBS does the right
thing on all platforms (though I wish it was an imported target to make
exports a bit nicer).


Regards,
Roger
--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Franck Houssen
----- Mail original -----
> De: "Roger Leigh" <[hidden email]>
> À: [hidden email]
> Envoyé: Samedi 6 Janvier 2018 18:42:11
> Objet: Re: [CMake] CMake: using dlopen
>
> On 06/01/18 17:01, J Decker wrote:
> > CMake/shared/modules will define the CMAKE_DL_LIBS  which a very high
> > percentage of the time will just be library 'dl' .

OK. I didn't know that. But if so, why don't you see CMAKE_DL_LIBS when you run "cmake -LA ." and/or when you toggle adanced mode in ccmake ? What's the correct way to see all variables ?

> >
> > Pretty much any man page on dlopen defines 'dl'
>
> On Linux.  On MaxOSX and FreeBSD not at all, where the dl functions are
> in libSystem and libc, respectively.  Using CMAKE_DL_LIBS does the right
> thing on all platforms (though I wish it was an imported target to make
> exports a bit nicer).

OK, thanks. So, I go with: target_link_libraries(main PUBLIC ... ${CMAKE_DL_LIBS})

>
>
> Regards,
> Roger
> --
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Konstantin Tokarev


> ----- Mail original -----
>
>> De: "Roger Leigh" <[hidden email]>
>> À: [hidden email]
>> Envoyé: Samedi 6 Janvier 2018 18:42:11
>> Objet: Re: [CMake] CMake: using dlopen
>>
>> On 06/01/18 17:01, J Decker wrote:
>>> CMake/shared/modules will define the CMAKE_DL_LIBS which a very high
>>> percentage of the time will just be library 'dl' .
>
> OK. I didn't know that. But if so, why don't you see CMAKE_DL_LIBS when you run "cmake -LA ." and/or when you toggle adanced mode in ccmake ? What's the correct way to see all variables ?

Because cmake -L shows only cached variables, not all variables

>
>>>
>>> Pretty much any man page on dlopen defines 'dl'
>>
>> On Linux. On MaxOSX and FreeBSD not at all, where the dl functions are
>> in libSystem and libc, respectively. Using CMAKE_DL_LIBS does the right
>> thing on all platforms (though I wish it was an imported target to make
>> exports a bit nicer).
>
> OK, thanks. So, I go with: target_link_libraries(main PUBLIC ... ${CMAKE_DL_LIBS})
>
>> Regards,
>> Roger
>> --
>>
>> 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
--
Regards,
Konstantin
--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Franck Houssen


----- Mail original -----

> De: "Konstantin Tokarev" <[hidden email]>
> À: "Franck Houssen" <[hidden email]>
> Cc: [hidden email], "Roger Leigh" <[hidden email]>
> Envoyé: Dimanche 7 Janvier 2018 15:20:08
> Objet: Re: [CMake] CMake: using dlopen
>
>
>
> > ----- Mail original -----
> >
> >> De: "Roger Leigh" <[hidden email]>
> >> À: [hidden email]
> >> Envoyé: Samedi 6 Janvier 2018 18:42:11
> >> Objet: Re: [CMake] CMake: using dlopen
> >>
> >> On 06/01/18 17:01, J Decker wrote:
> >>> CMake/shared/modules will define the CMAKE_DL_LIBS which a very high
> >>> percentage of the time will just be library 'dl' .
> >
> > OK. I didn't know that. But if so, why don't you see CMAKE_DL_LIBS when you
> > run "cmake -LA ." and/or when you toggle adanced mode in ccmake ? What's
> > the correct way to see all variables ?
>
> Because cmake -L shows only cached variables, not all variables
>

How to see all variables ?

> >
> >>>
> >>> Pretty much any man page on dlopen defines 'dl'
> >>
> >> On Linux. On MaxOSX and FreeBSD not at all, where the dl functions are
> >> in libSystem and libc, respectively. Using CMAKE_DL_LIBS does the right
> >> thing on all platforms (though I wish it was an imported target to make
> >> exports a bit nicer).
> >
> > OK, thanks. So, I go with: target_link_libraries(main PUBLIC ...
> > ${CMAKE_DL_LIBS})
> >
> >> Regards,
> >> Roger
> >> --
> >>
> >> 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
> --
> Regards,
> Konstantin
>
--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Konstantin Tokarev


07.01.2018, 19:36, "Franck Houssen" <[hidden email]>:

> ----- Mail original -----
>>  De: "Konstantin Tokarev" <[hidden email]>
>>  À: "Franck Houssen" <[hidden email]>
>>  Cc: [hidden email], "Roger Leigh" <[hidden email]>
>>  Envoyé: Dimanche 7 Janvier 2018 15:20:08
>>  Objet: Re: [CMake] CMake: using dlopen
>>
>>  > ----- Mail original -----
>>  >
>>  >> De: "Roger Leigh" <[hidden email]>
>>  >> À: [hidden email]
>>  >> Envoyé: Samedi 6 Janvier 2018 18:42:11
>>  >> Objet: Re: [CMake] CMake: using dlopen
>>  >>
>>  >> On 06/01/18 17:01, J Decker wrote:
>>  >>> CMake/shared/modules will define the CMAKE_DL_LIBS which a very high
>>  >>> percentage of the time will just be library 'dl' .
>>  >
>>  > OK. I didn't know that. But if so, why don't you see CMAKE_DL_LIBS when you
>>  > run "cmake -LA ." and/or when you toggle adanced mode in ccmake ? What's
>>  > the correct way to see all variables ?
>>
>>  Because cmake -L shows only cached variables, not all variables
>
> How to see all variables ?

See first part of https://stackoverflow.com/a/9328525

>
>>  >
>>  >>>
>>  >>> Pretty much any man page on dlopen defines 'dl'
>>  >>
>>  >> On Linux. On MaxOSX and FreeBSD not at all, where the dl functions are
>>  >> in libSystem and libc, respectively. Using CMAKE_DL_LIBS does the right
>>  >> thing on all platforms (though I wish it was an imported target to make
>>  >> exports a bit nicer).
>>  >
>>  > OK, thanks. So, I go with: target_link_libraries(main PUBLIC ...
>>  > ${CMAKE_DL_LIBS})
>>  >
>>  >> Regards,
>>  >> Roger
>>  >> --
>>  >>
>>  >> 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
>>  --
>>  Regards,
>>  Konstantin

--
Regards,
Konstantin
--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Roger Leigh
In reply to this post by Franck Houssen

-------- Original message --------
From: Franck Houssen <[hidden email]>
Date: 07/01/2018 13:58 (GMT+00:00)
To: Roger Leigh <[hidden email]>
Subject: Re: [CMake] CMake: using dlopen

> OK, thanks. So, I go with: target_link_libraries(main PUBLIC ... ${CMAKE_DL_LIBS})

Use PRIVATE if it is not used in any headers--it's an internal implementation detail.

Regards,
Roger

--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Franck Houssen
In reply to this post by Konstantin Tokarev


----- Mail original -----

> De: "Konstantin Tokarev" <[hidden email]>
> À: "Franck Houssen" <[hidden email]>
> Cc: [hidden email], "Roger Leigh" <[hidden email]>
> Envoyé: Dimanche 7 Janvier 2018 17:50:40
> Objet: Re: [CMake] CMake: using dlopen
>
>
>
> 07.01.2018, 19:36, "Franck Houssen" <[hidden email]>:
> > ----- Mail original -----
> >>  De: "Konstantin Tokarev" <[hidden email]>
> >>  À: "Franck Houssen" <[hidden email]>
> >>  Cc: [hidden email], "Roger Leigh" <[hidden email]>
> >>  Envoyé: Dimanche 7 Janvier 2018 15:20:08
> >>  Objet: Re: [CMake] CMake: using dlopen
> >>
> >>  > ----- Mail original -----
> >>  >
> >>  >> De: "Roger Leigh" <[hidden email]>
> >>  >> À: [hidden email]
> >>  >> Envoyé: Samedi 6 Janvier 2018 18:42:11
> >>  >> Objet: Re: [CMake] CMake: using dlopen
> >>  >>
> >>  >> On 06/01/18 17:01, J Decker wrote:
> >>  >>> CMake/shared/modules will define the CMAKE_DL_LIBS which a very high
> >>  >>> percentage of the time will just be library 'dl' .
> >>  >
> >>  > OK. I didn't know that. But if so, why don't you see CMAKE_DL_LIBS when
> >>  > you
> >>  > run "cmake -LA ." and/or when you toggle adanced mode in ccmake ?
> >>  > What's
> >>  > the correct way to see all variables ?
> >>
> >>  Because cmake -L shows only cached variables, not all variables
> >
> > How to see all variables ?
>
> See first part of https://stackoverflow.com/a/9328525
>

OK, I see ! Thanks

> >
> >>  >
> >>  >>>
> >>  >>> Pretty much any man page on dlopen defines 'dl'
> >>  >>
> >>  >> On Linux. On MaxOSX and FreeBSD not at all, where the dl functions are
> >>  >> in libSystem and libc, respectively. Using CMAKE_DL_LIBS does the
> >>  >> right
> >>  >> thing on all platforms (though I wish it was an imported target to
> >>  >> make
> >>  >> exports a bit nicer).
> >>  >
> >>  > OK, thanks. So, I go with: target_link_libraries(main PUBLIC ...
> >>  > ${CMAKE_DL_LIBS})
> >>  >
> >>  >> Regards,
> >>  >> Roger
> >>  >> --
> >>  >>
> >>  >> 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
> >>  --
> >>  Regards,
> >>  Konstantin
>
> --
> Regards,
> Konstantin
>
--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Franck Houssen
In reply to this post by Roger Leigh



De: "Roger Leigh" <[hidden email]>
À: "Franck Houssen" <[hidden email]>
Cc: [hidden email]
Envoyé: Dimanche 7 Janvier 2018 18:14:04
Objet: Re: [CMake] CMake: using dlopen


-------- Original message --------
From: Franck Houssen <[hidden email]>
Date: 07/01/2018 13:58 (GMT+00:00)
To: Roger Leigh <[hidden email]>
Subject: Re: [CMake] CMake: using dlopen

> OK, thanks. So, I go with: target_link_libraries(main PUBLIC ... ${CMAKE_DL_LIBS})

Use PRIVATE if it is not used in any headers--it's an internal implementation detail.

Difference between PUBLIC/PRIVATE has never been clear to me (usually I always use PUBLIC).
main.cpp includes dlfcn.h and uses it: not sure to get what you meant (PRIVATE is for templates ? when a header include headers ?)


Regards,
Roger


--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Konstantin Tokarev


07.01.2018, 21:13, "Franck Houssen" <[hidden email]>:

> ----------------------------------------
>> De: "Roger Leigh" <[hidden email]>
>> À: "Franck Houssen" <[hidden email]>
>> Cc: [hidden email]
>> Envoyé: Dimanche 7 Janvier 2018 18:14:04
>> Objet: Re: [CMake] CMake: using dlopen
>>
>> -------- Original message --------
>> From: Franck Houssen <[hidden email]>
>> Date: 07/01/2018 13:58 (GMT+00:00)
>> To: Roger Leigh <[hidden email]>
>> Cc: [hidden email]
>> Subject: Re: [CMake] CMake: using dlopen
>>
>>> OK, thanks. So, I go with: target_link_libraries(main PUBLIC ... ${CMAKE_DL_LIBS})
>>
>> Use PRIVATE if it is not used in any headers--it's an internal implementation detail.
>
> Difference between PUBLIC/PRIVATE has never been clear to me (usually I always use PUBLIC).
> main.cpp includes dlfcn.h and uses it: not sure to get what you meant (PRIVATE is for templates ? when a header include headers ?)

You should use target_link_libraries(A PUBLIC B) if and only if anything that links with library A must also link with library B (usually because B's types are used in public API of A). If A is not a library, there is no difference.

>
>> Regards,
>> Roger
>
> ,--
>
> 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


-- 
Regards,
Konstantin
--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Franck Houssen
In reply to this post by Franck Houssen


----- Mail original -----

> De: "Rainer Poisel" <[hidden email]>
> À: "Franck Houssen" <[hidden email]>
> Envoyé: Dimanche 7 Janvier 2018 19:34:21
> Objet: Re: [CMake] CMake: using dlopen
>
> Hi,
>
> On Sun, Jan 7, 2018 at 7:13 PM, Franck Houssen <[hidden email]>
> wrote:
> > Difference between PUBLIC/PRIVATE has never been clear to me (usually I
> > always use PUBLIC).
> > main.cpp includes dlfcn.h and uses it: not sure to get what you meant
> > (PRIVATE is for templates ? when a header include headers ?)
>
> you are looking for the "Transitive Dependencies" feature of CMake:

OK, I didn't get that. It's more clear to me now. Thanks !

>   *
>   https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#transitive-usage-requirements
>
> Generally speaking and from my personal experience, use the
> target_-commands as much as possible because properties are bound to
> targets and their dependencies rather than a file/directory structure.
>
> So, that means, use target_include_directories(),
> target_compile_options(), target_compile_definitions(),
> target_sources(), ... for your targets. The magic keyword to propagate
> the properties of your targets is target_link_libraries(). Depending
> on what scope (PRIVATE, PUBLIC, INTERFACE) the properties have been
> defined using the other target_-commands, the target_link_libraries()
> command propagates these properties to other targets. E. g.
>
> add_library(otherlib SHARED
>   foo.c
> )
>
> target_include_directories(otherlib PRIVATE
>   dirPrivate
> )
>
> target_include_directories(otherlib PUBLIC
>   dirPublic
> )
>
> add_library(mylib SHARED
>   bar.c
> )
>
> target_link_libraries(mylib PRIVATE

Is this a typo ?
For the example to work I would have done: target_link_libraries(mylib PUBLIC otherLib), no ? (mylib needs only PUBLIC stuff's from otherLib but not PRIVATE one's). Correct ?


>   otherlib
> )
>
> In this case, mylib will use all PUBLIC or INTERFACE properties of
> otherlib for its build. Thus, dirPublic will be added to the include
> directory search path for the compilation of bar.c of mylib. PRIVATE
> properties will not be propagated. In the above mentioned example,
> dirPrivate will NOT be added to the include directory search path for
> the compilation of bar.c of mylib.
>

The example is illustrative (transitivity - PRIVATE is not propagated)

> This is a very short summary, but I hope it is of help to you. There
> are other ressources on the Internet. E. g.
>   *
>   https://stackoverflow.com/questions/26037954/cmake-target-link-libraries-interface-dependencies
>   * https://rix0r.nl/blog/2015/08/13/cmake-guide/
>
> Regards,
>   Rainer
>
--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

J Decker

On Mon, Jan 8, 2018 at 1:41 AM, Franck Houssen <[hidden email]> wrote:


----- Mail original -----
> De: "Rainer Poisel" <[hidden email]>
> À: "Franck Houssen" <[hidden email]>
> Envoyé: Dimanche 7 Janvier 2018 19:34:21
> Objet: Re: [CMake] CMake: using dlopen
>
> Hi,
>
> On Sun, Jan 7, 2018 at 7:13 PM, Franck Houssen <[hidden email]>
> wrote:
> > Difference between PUBLIC/PRIVATE has never been clear to me (usually I
> > always use PUBLIC).
> > main.cpp includes dlfcn.h and uses it: not sure to get what you meant
> > (PRIVATE is for templates ? when a header include headers ?)
>
> you are looking for the "Transitive Dependencies" feature of CMake:

OK, I didn't get that. It's more clear to me now. Thanks !

>   *
>   https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#transitive-usage-requirements
>
> Generally speaking and from my personal experience, use the
> target_-commands as much as possible because properties are bound to
> targets and their dependencies rather than a file/directory structure.
>
> So, that means, use target_include_directories(),
> target_compile_options(), target_compile_definitions(),
> target_sources(), ... for your targets. The magic keyword to propagate
> the properties of your targets is target_link_libraries(). Depending
> on what scope (PRIVATE, PUBLIC, INTERFACE) the properties have been
> defined using the other target_-commands, the target_link_libraries()
> command propagates these properties to other targets. E. g.
>
> add_library(otherlib SHARED
>   foo.c
> )
>
> target_include_directories(otherlib PRIVATE
>   dirPrivate
> )
>
> target_include_directories(otherlib PUBLIC
>   dirPublic
> )
>
> add_library(mylib SHARED
>   bar.c
> )
>
> target_link_libraries(mylib PRIVATE

Is this a typo ?
For the example to work I would have done: target_link_libraries(mylib PUBLIC otherLib), no ? (mylib needs only PUBLIC stuff's from otherLib but not PRIVATE one's). Correct ?


Public is whether it propagates outside of the current target to things that then require 'mylib' 
private keeps it within that target, has nothing to do with what it's pulling from any linked library.
 

>   otherlib
> )
>
> In this case, mylib will use all PUBLIC or INTERFACE properties of
> otherlib for its build. Thus, dirPublic will be added to the include
> directory search path for the compilation of bar.c of mylib. PRIVATE
> properties will not be propagated. In the above mentioned example,
> dirPrivate will NOT be added to the include directory search path for
> the compilation of bar.c of mylib.
>

The example is illustrative (transitivity - PRIVATE is not propagated)

> This is a very short summary, but I hope it is of help to you. There
> are other ressources on the Internet. E. g.
>   *
>   https://stackoverflow.com/questions/26037954/cmake-target-link-libraries-interface-dependencies
>   * https://rix0r.nl/blog/2015/08/13/cmake-guide/
>
> Regards,
>   Rainer
>
--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Franck Houssen
In reply to this post by Franck Houssen
And so, if I have an executable (add_executable), the default thing to do is to use target_link_libraries(mylib PRIVATE ...). Not PUBLIC (as I do). Correct ?

----- Mail original -----

> De: "Franck Houssen" <[hidden email]>
> À: "Rainer Poisel" <[hidden email]>
> Cc: "CMake Mail List" <[hidden email]>
> Envoyé: Lundi 8 Janvier 2018 10:41:25
> Objet: Re: [CMake] CMake: using dlopen
>
>
>
> ----- Mail original -----
> > De: "Rainer Poisel" <[hidden email]>
> > À: "Franck Houssen" <[hidden email]>
> > Envoyé: Dimanche 7 Janvier 2018 19:34:21
> > Objet: Re: [CMake] CMake: using dlopen
> >
> > Hi,
> >
> > On Sun, Jan 7, 2018 at 7:13 PM, Franck Houssen <[hidden email]>
> > wrote:
> > > Difference between PUBLIC/PRIVATE has never been clear to me (usually I
> > > always use PUBLIC).
> > > main.cpp includes dlfcn.h and uses it: not sure to get what you meant
> > > (PRIVATE is for templates ? when a header include headers ?)
> >
> > you are looking for the "Transitive Dependencies" feature of CMake:
>
> OK, I didn't get that. It's more clear to me now. Thanks !
>
> >   *
> >   https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#transitive-usage-requirements
> >
> > Generally speaking and from my personal experience, use the
> > target_-commands as much as possible because properties are bound to
> > targets and their dependencies rather than a file/directory structure.
> >
> > So, that means, use target_include_directories(),
> > target_compile_options(), target_compile_definitions(),
> > target_sources(), ... for your targets. The magic keyword to propagate
> > the properties of your targets is target_link_libraries(). Depending
> > on what scope (PRIVATE, PUBLIC, INTERFACE) the properties have been
> > defined using the other target_-commands, the target_link_libraries()
> > command propagates these properties to other targets. E. g.
> >
> > add_library(otherlib SHARED
> >   foo.c
> > )
> >
> > target_include_directories(otherlib PRIVATE
> >   dirPrivate
> > )
> >
> > target_include_directories(otherlib PUBLIC
> >   dirPublic
> > )
> >
> > add_library(mylib SHARED
> >   bar.c
> > )
> >
> > target_link_libraries(mylib PRIVATE
>
> Is this a typo ?
> For the example to work I would have done: target_link_libraries(mylib PUBLIC
> otherLib), no ? (mylib needs only PUBLIC stuff's from otherLib but not
> PRIVATE one's). Correct ?
>
>
> >   otherlib
> > )
> >
> > In this case, mylib will use all PUBLIC or INTERFACE properties of
> > otherlib for its build. Thus, dirPublic will be added to the include
> > directory search path for the compilation of bar.c of mylib. PRIVATE
> > properties will not be propagated. In the above mentioned example,
> > dirPrivate will NOT be added to the include directory search path for
> > the compilation of bar.c of mylib.
> >
>
> The example is illustrative (transitivity - PRIVATE is not propagated)
>
> > This is a very short summary, but I hope it is of help to you. There
> > are other ressources on the Internet. E. g.
> >   *
> >   https://stackoverflow.com/questions/26037954/cmake-target-link-libraries-interface-dependencies
> >   * https://rix0r.nl/blog/2015/08/13/cmake-guide/
> >
> > Regards,
> >   Rainer
> >
> --
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

J Decker


On Mon, Jan 8, 2018 at 1:50 AM, Franck Houssen <[hidden email]> wrote:
And so, if I have an executable (add_executable), the default thing to do is to use target_link_libraries(mylib PRIVATE ...). Not PUBLIC (as I do). Correct ?
 
Yes, unless you have plugins that then back-ljnk against that executable. (and that also use the libraries that executable uses... if it just uses things from that library/executable then private should always be used)  
 

----- Mail original -----
> De: "Franck Houssen" <[hidden email]>
> À: "Rainer Poisel" <[hidden email]>
> Cc: "CMake Mail List" <[hidden email]>
> Envoyé: Lundi 8 Janvier 2018 10:41:25
> Objet: Re: [CMake] CMake: using dlopen
>
>
>
> ----- Mail original -----
> > De: "Rainer Poisel" <[hidden email]>
> > À: "Franck Houssen" <[hidden email]>
> > Envoyé: Dimanche 7 Janvier 2018 19:34:21
> > Objet: Re: [CMake] CMake: using dlopen
> >
> > Hi,
> >
> > On Sun, Jan 7, 2018 at 7:13 PM, Franck Houssen <[hidden email]>
> > wrote:
> > > Difference between PUBLIC/PRIVATE has never been clear to me (usually I
> > > always use PUBLIC).
> > > main.cpp includes dlfcn.h and uses it: not sure to get what you meant
> > > (PRIVATE is for templates ? when a header include headers ?)
> >
> > you are looking for the "Transitive Dependencies" feature of CMake:
>
> OK, I didn't get that. It's more clear to me now. Thanks !
>
> >   *
> >   https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#transitive-usage-requirements
> >
> > Generally speaking and from my personal experience, use the
> > target_-commands as much as possible because properties are bound to
> > targets and their dependencies rather than a file/directory structure.
> >
> > So, that means, use target_include_directories(),
> > target_compile_options(), target_compile_definitions(),
> > target_sources(), ... for your targets. The magic keyword to propagate
> > the properties of your targets is target_link_libraries(). Depending
> > on what scope (PRIVATE, PUBLIC, INTERFACE) the properties have been
> > defined using the other target_-commands, the target_link_libraries()
> > command propagates these properties to other targets. E. g.
> >
> > add_library(otherlib SHARED
> >   foo.c
> > )
> >
> > target_include_directories(otherlib PRIVATE
> >   dirPrivate
> > )
> >
> > target_include_directories(otherlib PUBLIC
> >   dirPublic
> > )
> >
> > add_library(mylib SHARED
> >   bar.c
> > )
> >
> > target_link_libraries(mylib PRIVATE
>
> Is this a typo ?
> For the example to work I would have done: target_link_libraries(mylib PUBLIC
> otherLib), no ? (mylib needs only PUBLIC stuff's from otherLib but not
> PRIVATE one's). Correct ?
>
>
> >   otherlib
> > )
> >
> > In this case, mylib will use all PUBLIC or INTERFACE properties of
> > otherlib for its build. Thus, dirPublic will be added to the include
> > directory search path for the compilation of bar.c of mylib. PRIVATE
> > properties will not be propagated. In the above mentioned example,
> > dirPrivate will NOT be added to the include directory search path for
> > the compilation of bar.c of mylib.
> >
>
> The example is illustrative (transitivity - PRIVATE is not propagated)
>
> > This is a very short summary, but I hope it is of help to you. There
> > are other ressources on the Internet. E. g.
> >   *
> >   https://stackoverflow.com/questions/26037954/cmake-target-link-libraries-interface-dependencies
> >   * https://rix0r.nl/blog/2015/08/13/cmake-guide/
> >
> > Regards,
> >   Rainer
> >
> --
>
> 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


--

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
Reply | Threaded
Open this post in threaded view
|

Re: CMake: using dlopen

Eric Noulard
In reply to this post by J Decker
Explanations on PRIVATE, PUBLIC, INTERFACE has already been discussed in those ML threads:

I guess we need some doc update.
I did promess contribution and I didn't do it.
I'll try again.


2018-01-08 10:45 GMT+01:00 J Decker <[hidden email]>:

On Mon, Jan 8, 2018 at 1:41 AM, Franck Houssen <[hidden email]> wrote:


----- Mail original -----
> De: "Rainer Poisel" <[hidden email]>
> À: "Franck Houssen" <[hidden email]>
> Envoyé: Dimanche 7 Janvier 2018 19:34:21
> Objet: Re: [CMake] CMake: using dlopen
>
> Hi,
>
> On Sun, Jan 7, 2018 at 7:13 PM, Franck Houssen <[hidden email]>
> wrote:
> > Difference between PUBLIC/PRIVATE has never been clear to me (usually I
> > always use PUBLIC).
> > main.cpp includes dlfcn.h and uses it: not sure to get what you meant
> > (PRIVATE is for templates ? when a header include headers ?)
>
> you are looking for the "Transitive Dependencies" feature of CMake:

OK, I didn't get that. It's more clear to me now. Thanks !

>   *
>   https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#transitive-usage-requirements
>
> Generally speaking and from my personal experience, use the
> target_-commands as much as possible because properties are bound to
> targets and their dependencies rather than a file/directory structure.
>
> So, that means, use target_include_directories(),
> target_compile_options(), target_compile_definitions(),
> target_sources(), ... for your targets. The magic keyword to propagate
> the properties of your targets is target_link_libraries(). Depending
> on what scope (PRIVATE, PUBLIC, INTERFACE) the properties have been
> defined using the other target_-commands, the target_link_libraries()
> command propagates these properties to other targets. E. g.
>
> add_library(otherlib SHARED
>   foo.c
> )
>
> target_include_directories(otherlib PRIVATE
>   dirPrivate
> )
>
> target_include_directories(otherlib PUBLIC
>   dirPublic
> )
>
> add_library(mylib SHARED
>   bar.c
> )
>
> target_link_libraries(mylib PRIVATE

Is this a typo ?
For the example to work I would have done: target_link_libraries(mylib PUBLIC otherLib), no ? (mylib needs only PUBLIC stuff's from otherLib but not PRIVATE one's). Correct ?


Public is whether it propagates outside of the current target to things that then require 'mylib' 
private keeps it within that target, has nothing to do with what it's pulling from any linked library.
 

>   otherlib
> )
>
> In this case, mylib will use all PUBLIC or INTERFACE properties of
> otherlib for its build. Thus, dirPublic will be added to the include
> directory search path for the compilation of bar.c of mylib. PRIVATE
> properties will not be propagated. In the above mentioned example,
> dirPrivate will NOT be added to the include directory search path for
> the compilation of bar.c of mylib.
>

The example is illustrative (transitivity - PRIVATE is not propagated)

> This is a very short summary, but I hope it is of help to you. There
> are other ressources on the Internet. E. g.
>   *
>   https://stackoverflow.com/questions/26037954/cmake-target-link-libraries-interface-dependencies
>   * https://rix0r.nl/blog/2015/08/13/cmake-guide/
>
> Regards,
>   Rainer
>
--

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




--
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
12