On 6/14/07, <b class="gmail_sendername">Alan W. Irwin</b> &lt;<a href="mailto:irwin@beluga.phys.uvic.ca">irwin@beluga.phys.uvic.ca</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 2007-06-14 08:58+0800 Clark J. Wang wrote:<br><br>&gt; Shared libs have different suffixes on different OSes. For example on Linux<br>&gt; the suffix is `.so&#39; and on Mac OS X it&#39;s `.dylib&#39;. I want to use `dlopen()&#39;
<br>&gt; in my code so I want to get the suffix and then define it in a header file.<br>&gt; Can I do that in CMake? And how?<br><br>You could write a CMake test to create a shared object, gets its full name,<br>and parse for the suffix.&nbsp;&nbsp;However, that is a non-trivial amount of cmake
<br>script development (at least it would be for me) so let me discuss an<br>alternative that might work a little easier for you.</blockquote><div><br>I&#39;ll try to write a script to do that later.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Before getting to specifics, note on Unix there is a distinction between a<br>shared library (a shared object opened at the start of run time by the<br>run-time loader) and what I will call a plug-in (a shared object that is
<br>&quot;dlopened&quot; by an executable or library _some time_ during the course of run<br>time). For example, there are naming conventions that must be used by shared<br>libraries, (e.g., the library name must start with &quot;lib&quot;), but AFAIK those
<br>naming conventions don&#39;t apply to plug-ins.&nbsp;&nbsp;So what I have done for the<br>PLplot plug-ins is always build them with a suffix of &quot;.so&quot; regardless of<br>platform.&nbsp;&nbsp;The resulting plug-ins seems to work fine both on Linux and Mac
<br>OS X.&nbsp;&nbsp;Note, we use the libltdl library (the only remnant of autotools still<br>left in our CMake build system for PLplot) to provide a uniform wrapper for<br>dlopen and its various equivalents on non-Linux platforms.&nbsp;&nbsp;That library
<br>seems happy with the *.so names for plug-ins for the limited testing<br>(I think just Linux and Mac OS X) that we have done so far.</blockquote><div><br>Sounds like this is a good way to work around. Dlopen does not care about the library suffixes :-)
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Anyway, you may want to give the *.so name for plug-ins idea a try (with or<br>
without libltdl) if you don&#39;t want to fiddle around creating a cmake test to<br>find out what the shared object suffix is on each of your platforms.<br><br>Alan<br>__________________________<br>Alan W. Irwin<br><br>Astronomical research affiliation with Department of Physics and Astronomy,
<br>University of Victoria (<a href="http://astrowww.phys.uvic.ca">astrowww.phys.uvic.ca</a>).<br><br>Programming affiliations with the FreeEOS equation-of-state implementation<br>for stellar interiors (<a href="http://freeeos.sf.net">
freeeos.sf.net</a>); PLplot scientific plotting software<br>package (<a href="http://plplot.org">plplot.org</a>); the libLASi project (<a href="http://unifont.org/lasi">unifont.org/lasi</a>); the Loads of<br>Linux Links project (
<a href="http://loll.sf.net">loll.sf.net</a>); and the Linux Brochure Project<br>(<a href="http://lbproject.sf.net">lbproject.sf.net</a>).<br>__________________________<br><br>Linux-powered Science<br>__________________________
<br></blockquote></div><br>