The component presumes that dynamic libraries end in ".so". On Mac, they typically (though I believe not always) end in ".dylib". Hence on a Mac you can _not_ load a dynamic library into the deployer (it keeps tacking on a .so).
Propose to either
1) change the deployment component to search for ".so" on non-Mac and ".dylib" on Mac (easiest approach, just compile-time set the extension of interest), OR
2) add ".dylib" search as well as ".so" search on Mac (many more changes required).
Changing the deployer to simply not tack on the .so if it finds a .dylib extension, isn't that useful as it prevents the use of the same .xml file in both Linux and Mac settings (which we have).
Thoughts?
S
Deployment component ignores .dylib libraries on Mac
> The component presumes that dynamic libraries end in ".so". On Mac, they
> typically (though I believe not always) end in ".dylib". Hence on a Mac
> you can _not_ load a dynamic library into the deployer (it keeps tacking
> on a .so).
>
> Propose to either
> 1) change the deployment component to search for ".so" on non-Mac and
> ".dylib" on Mac (easiest approach, just compile-time set the extension of
> interest), OR
> 2) add ".dylib" search as well as ".so" search on Mac (many more changes
> required).
>
> Changing the deployer to simply not tack on the .so if it finds a .dylib
> extension, isn't that useful as it prevents the use of the same .xml file
> in both Linux and Mac settings (which we have).
>
> Thoughts?
Option 1. We could make it a property as well and set the default at
compile time (but you don't want to change that so I wonder if a property
is that useful...).
Which reminds me that there should be a way to configure the Deployment
component first (before all) using a separate XML file or so to be able to
set the search path and other such variable, site-specific options.
For example, if it finds a file 'site.cpf' or '.cpf;, it
loads it in configureHook() for settings its properties.
Useful ?
Peter
Deployment component ignores .dylib libraries on Mac
On Nov 27, 2008, at 12:36 , Peter Soetens wrote:
>> The component presumes that dynamic libraries end in ".so". On Mac,.cpf;, it
>> they
>> typically (though I believe not always) end in ".dylib". Hence on a
>> Mac
>> you can _not_ load a dynamic library into the deployer (it keeps
>> tacking
>> on a .so).
>>
>> Propose to either
>> 1) change the deployment component to search for ".so" on non-Mac and
>> ".dylib" on Mac (easiest approach, just compile-time set the
>> extension of
>> interest), OR
>> 2) add ".dylib" search as well as ".so" search on Mac (many more
>> changes
>> required).
>>
>> Changing the deployer to simply not tack on the .so if it finds
>> a .dylib
>> extension, isn't that useful as it prevents the use of the
>> same .xml file
>> in both Linux and Mac settings (which we have).
>>
>> Thoughts?
>
> Option 1. We could make it a property as well and set the default at
> compile time (but you don't want to change that so I wonder if a
> property
> is that useful...).
>
> Which reminds me that there should be a way to configure the
> Deployment
> component first (before all) using a separate XML file or so to be
> able to
> set the search path and other such variable, site-specific options.
>
> For example, if it finds a file 'site.cpf' or '
> loads it in configureHook() for settings its properties.
>
> Useful ?
We've talked before about paths and the like, and didn't come to any
conclusions. What other options can you think of, that the deployer
could load from XML?
Changing the extension within the deployer ala Option 1 works fine for
me. I'm specifying the library as "libxxx" within the deployment file,
and then setting DYLD_LIBRARY_PATH to let the dynamic loader find the
library. As a patch, this needs a little more work to remove all .so
uses, but it won't be a big deal.
S
Deployment component ignores .dylib libraries on Mac
This thread becomes a bit to much orocos-dev... please move the thread to that
place.
On Thursday 27 November 2008 19:33:34 S Roderick wrote:.cpf;, it
> On Nov 27, 2008, at 12:36 , Peter Soetens wrote:
> >> The component presumes that dynamic libraries end in ".so". On Mac,
> >> they
> >> typically (though I believe not always) end in ".dylib". Hence on a
> >> Mac
> >> you can _not_ load a dynamic library into the deployer (it keeps
> >> tacking
> >> on a .so).
> >>
> >> Propose to either
> >> 1) change the deployment component to search for ".so" on non-Mac and
> >> ".dylib" on Mac (easiest approach, just compile-time set the
> >> extension of
> >> interest), OR
> >> 2) add ".dylib" search as well as ".so" search on Mac (many more
> >> changes
> >> required).
> >>
> >> Changing the deployer to simply not tack on the .so if it finds
> >> a .dylib
> >> extension, isn't that useful as it prevents the use of the
> >> same .xml file
> >> in both Linux and Mac settings (which we have).
> >>
> >> Thoughts?
> >
> > Option 1. We could make it a property as well and set the default at
> > compile time (but you don't want to change that so I wonder if a
> > property
> > is that useful...).
> >
> > Which reminds me that there should be a way to configure the
> > Deployment
> > component first (before all) using a separate XML file or so to be
> > able to
> > set the search path and other such variable, site-specific options.
> >
> > For example, if it finds a file 'site.cpf' or '
> > loads it in configureHook() for settings its properties.
> >
> > Useful ?
>
> We've talked before about paths and the like, and didn't come to any
> conclusions. What other options can you think of, that the deployer
> could load from XML?
I actually can't think of many other things to set at that time than the
library search path(s). In that respect, it looks overkill again.
Somewhat related, today, it's possible to configure the deployer from your main
XML file. It has come to my attention that some people do not like the XML and
would prefer to describe the application as a program script (which is already
possible today). In that case, the XML file just configures and starts the
deployer and we'd need to extend it such that programs and state machines are
started automatically (as noted in a bug report). While we're at it, instead
of specifying a 'PropertyFile', we could extend the XML file to allow to
specify the properties as well, using a
>
> Changing the extension within the deployer ala Option 1 works fine for
> me. I'm specifying the library as "libxxx" within the deployment file,
> and then setting DYLD_LIBRARY_PATH to let the dynamic loader find the
> library. As a patch, this needs a little more work to remove all .so
> uses, but it won't be a big deal.
So you would agree with Ruben's patch ?
Peter
Deployment component ignores .dylib libraries on Mac
This thread becomes a bit to much orocos-dev... please move the thread to that
place.
On Thursday 27 November 2008 19:33:34 S Roderick wrote:.cpf;, it
> On Nov 27, 2008, at 12:36 , Peter Soetens wrote:
> >> The component presumes that dynamic libraries end in ".so". On Mac,
> >> they
> >> typically (though I believe not always) end in ".dylib". Hence on a
> >> Mac
> >> you can _not_ load a dynamic library into the deployer (it keeps
> >> tacking
> >> on a .so).
> >>
> >> Propose to either
> >> 1) change the deployment component to search for ".so" on non-Mac and
> >> ".dylib" on Mac (easiest approach, just compile-time set the
> >> extension of
> >> interest), OR
> >> 2) add ".dylib" search as well as ".so" search on Mac (many more
> >> changes
> >> required).
> >>
> >> Changing the deployer to simply not tack on the .so if it finds
> >> a .dylib
> >> extension, isn't that useful as it prevents the use of the
> >> same .xml file
> >> in both Linux and Mac settings (which we have).
> >>
> >> Thoughts?
> >
> > Option 1. We could make it a property as well and set the default at
> > compile time (but you don't want to change that so I wonder if a
> > property
> > is that useful...).
> >
> > Which reminds me that there should be a way to configure the
> > Deployment
> > component first (before all) using a separate XML file or so to be
> > able to
> > set the search path and other such variable, site-specific options.
> >
> > For example, if it finds a file 'site.cpf' or '
> > loads it in configureHook() for settings its properties.
> >
> > Useful ?
>
> We've talked before about paths and the like, and didn't come to any
> conclusions. What other options can you think of, that the deployer
> could load from XML?
I actually can't think of many other things to set at that time than the
library search path(s). In that respect, it looks overkill again.
Somewhat related, today, it's possible to configure the deployer from your main
XML file. It has come to my attention that some people do not like the XML and
would prefer to describe the application as a program script (which is already
possible today). In that case, the XML file just configures and starts the
deployer and we'd need to extend it such that programs and state machines are
started automatically (as noted in a bug report). While we're at it, instead
of specifying a 'PropertyFile', we could extend the XML file to allow to
specify the properties as well, using a
>
> Changing the extension within the deployer ala Option 1 works fine for
> me. I'm specifying the library as "libxxx" within the deployment file,
> and then setting DYLD_LIBRARY_PATH to let the dynamic loader find the
> library. As a patch, this needs a little more work to remove all .so
> uses, but it won't be a big deal.
So you would agree with Ruben's patch ?
Peter
Deployment component ignores .dylib libraries on Mac
> On Thursday 27 November 2008 19:33:34 S Roderick wrote:.cpf;, it
>> On Nov 27, 2008, at 12:36 , Peter Soetens wrote:
>>>> The component presumes that dynamic libraries end in ".so". On Mac,
>>>> they
>>>> typically (though I believe not always) end in ".dylib". Hence on a
>>>> Mac
>>>> you can _not_ load a dynamic library into the deployer (it keeps
>>>> tacking
>>>> on a .so).
>>>>
>>>> Propose to either
>>>> 1) change the deployment component to search for ".so" on non-Mac
>>>> and
>>>> ".dylib" on Mac (easiest approach, just compile-time set the
>>>> extension of
>>>> interest), OR
>>>> 2) add ".dylib" search as well as ".so" search on Mac (many more
>>>> changes
>>>> required).
>>>>
>>>> Changing the deployer to simply not tack on the .so if it finds
>>>> a .dylib
>>>> extension, isn't that useful as it prevents the use of the
>>>> same .xml file
>>>> in both Linux and Mac settings (which we have).
>>>>
>>>> Thoughts?
>>>
>>> Option 1. We could make it a property as well and set the default at
>>> compile time (but you don't want to change that so I wonder if a
>>> property
>>> is that useful...).
>>>
>>> Which reminds me that there should be a way to configure the
>>> Deployment
>>> component first (before all) using a separate XML file or so to be
>>> able to
>>> set the search path and other such variable, site-specific options.
>>>
>>> For example, if it finds a file 'site.cpf' or
>>> '
>>> loads it in configureHook() for settings its properties.
>>>
>>> Useful ?
>>
>> We've talked before about paths and the like, and didn't come to any
>> conclusions. What other options can you think of, that the deployer
>> could load from XML?
>
> I actually can't think of many other things to set at that time than
> the
> library search path(s). In that respect, it looks overkill again.
I guess the Mac with DYLD_LIBRARY_PATH has an easy method for users to
configure the dynamic loading path externally. Linux now longer uses
this, instead dealing with ld.so.conf which is not necessarily user-
friendly nor non-priviledged accessible. Does sound like we need
something to be able to specify one or more search paths.
> Somewhat related, today, it's possible to configure the deployer
> from your main
> XML file. It has come to my attention that some people do not like
> the XML and
> would prefer to describe the application as a program script (which
> is already
> possible today). In that case, the XML file just configures and
> starts the
> deployer and we'd need to extend it such that programs and state
> machines are
> started automatically (as noted in a bug report). While we're at it,
> instead
> of specifying a 'PropertyFile', we could extend the XML file to
> allow to
> specify the properties as well, using a
Able "configure the deployer from your main XML file". Configure it in
what way?
What would be a basic example of "describing the application as a
program script"?
Extend XML to "specify properties as well". Do you have an example?
>> Changing the extension within the deployer ala Option 1 works fine
>> for
>> me. I'm specifying the library as "libxxx" within the deployment
>> file,
>> and then setting DYLD_LIBRARY_PATH to let the dynamic loader find the
>> library. As a patch, this needs a little more work to remove all .so
>> uses, but it won't be a big deal.
>
> So you would agree with Ruben's patch ?
Ahh ... seems a little heavy handed. How about the following? This
saves copying code and making the file unnecessarily bigger (leading
to slower compiles, and potentially more bugs).
S
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Deployment component ignores .dylib libraries on Mac
On 04 Dec 2008, at 13:48, S Roderick wrote:
>> On Thursday 27 November 2008 19:33:34 S Roderick wrote:.cpf;, it
>>> On Nov 27, 2008, at 12:36 , Peter Soetens wrote:
>>>>> The component presumes that dynamic libraries end in ".so". On
>>>>> Mac,
>>>>> they
>>>>> typically (though I believe not always) end in ".dylib". Hence
>>>>> on a
>>>>> Mac
>>>>> you can _not_ load a dynamic library into the deployer (it keeps
>>>>> tacking
>>>>> on a .so).
>>>>>
>>>>> Propose to either
>>>>> 1) change the deployment component to search for ".so" on non-Mac
>>>>> and
>>>>> ".dylib" on Mac (easiest approach, just compile-time set the
>>>>> extension of
>>>>> interest), OR
>>>>> 2) add ".dylib" search as well as ".so" search on Mac (many more
>>>>> changes
>>>>> required).
>>>>>
>>>>> Changing the deployer to simply not tack on the .so if it finds
>>>>> a .dylib
>>>>> extension, isn't that useful as it prevents the use of the
>>>>> same .xml file
>>>>> in both Linux and Mac settings (which we have).
>>>>>
>>>>> Thoughts?
>>>>
>>>> Option 1. We could make it a property as well and set the default
>>>> at
>>>> compile time (but you don't want to change that so I wonder if a
>>>> property
>>>> is that useful...).
>>>>
>>>> Which reminds me that there should be a way to configure the
>>>> Deployment
>>>> component first (before all) using a separate XML file or so to be
>>>> able to
>>>> set the search path and other such variable, site-specific options.
>>>>
>>>> For example, if it finds a file 'site.cpf' or
>>>> '
>>>> loads it in configureHook() for settings its properties.
>>>>
>>>> Useful ?
>>>
>>> We've talked before about paths and the like, and didn't come to any
>>> conclusions. What other options can you think of, that the deployer
>>> could load from XML?
>>
>> I actually can't think of many other things to set at that time than
>> the
>> library search path(s). In that respect, it looks overkill again.
>
> I guess the Mac with DYLD_LIBRARY_PATH has an easy method for users to
> configure the dynamic loading path externally. Linux now longer uses
> this, instead dealing with ld.so.conf which is not necessarily user-
> friendly nor non-priviledged accessible. Does sound like we need
> something to be able to specify one or more search paths.
>
>> Somewhat related, today, it's possible to configure the deployer
>> from your main
>> XML file. It has come to my attention that some people do not like
>> the XML and
>> would prefer to describe the application as a program script (which
>> is already
>> possible today). In that case, the XML file just configures and
>> starts the
>> deployer and we'd need to extend it such that programs and state
>> machines are
>> started automatically (as noted in a bug report). While we're at it,
>> instead
>> of specifying a 'PropertyFile', we could extend the XML file to
>> allow to
>> specify the properties as well, using a
>
> Able "configure the deployer from your main XML file". Configure it in
> what way?
>
> What would be a basic example of "describing the application as a
> program script"?
>
> Extend XML to "specify properties as well". Do you have an example?
>
>>> Changing the extension within the deployer ala Option 1 works fine
>>> for
>>> me. I'm specifying the library as "libxxx" within the deployment
>>> file,
>>> and then setting DYLD_LIBRARY_PATH to let the dynamic loader find
>>> the
>>> library. As a patch, this needs a little more work to remove all .so
>>> uses, but it won't be a big deal.
>>
>> So you would agree with Ruben's patch ?
>
> Ahh ... seems a little heavy handed. How about the following? This
> saves copying code and making the file unnecessarily bigger (leading
> to slower compiles, and potentially more bugs).
> S
>
This patch is a lot cleaner, if i had to choose i would apply yours ;)
Ruben
Deployment component ignores .dylib libraries on Mac
On 27 Nov 2008, at 19:33, S Roderick wrote:
> On Nov 27, 2008, at 12:36 , Peter Soetens wrote:.cpf;,
>
>>> The component presumes that dynamic libraries end in ".so". On Mac,
>>> they
>>> typically (though I believe not always) end in ".dylib". Hence on a
>>> Mac
>>> you can _not_ load a dynamic library into the deployer (it keeps
>>> tacking
>>> on a .so).
>>>
>>> Propose to either
>>> 1) change the deployment component to search for ".so" on non-Mac
>>> and
>>> ".dylib" on Mac (easiest approach, just compile-time set the
>>> extension of
>>> interest), OR
>>> 2) add ".dylib" search as well as ".so" search on Mac (many more
>>> changes
>>> required).
>>>
>>> Changing the deployer to simply not tack on the .so if it finds
>>> a .dylib
>>> extension, isn't that useful as it prevents the use of the
>>> same .xml file
>>> in both Linux and Mac settings (which we have).
>>>
>>> Thoughts?
>>
>> Option 1. We could make it a property as well and set the default at
>> compile time (but you don't want to change that so I wonder if a
>> property
>> is that useful...).
>>
>> Which reminds me that there should be a way to configure the
>> Deployment
>> component first (before all) using a separate XML file or so to be
>> able to
>> set the search path and other such variable, site-specific options.
>>
>> For example, if it finds a file 'site.cpf' or '
>> it
>> loads it in configureHook() for settings its properties.
>>
>> Useful ?
>
> We've talked before about paths and the like, and didn't come to any
> conclusions. What other options can you think of, that the deployer
> could load from XML?
>
> Changing the extension within the deployer ala Option 1 works fine for
> me. I'm specifying the library as "libxxx" within the deployment file,
> and then setting DYLD_LIBRARY_PATH to let the dynamic loader find the
> library. As a patch, this needs a little more work to remove all .so
> uses, but it won't be a big deal.
The attached patch fixes the issues by using the #define __APPLE__, I
don't know if this is what you had in mind, but i tested it and it
works for me :).
Ruben
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Deployment component ignores .dylib libraries on Mac
The component presumes that dynamic libraries end in ".so". On Mac, they typically (though I believe not always) end in ".dylib". Hence on a Mac you can _not_ load a dynamic library into the deployer (it keeps tacking on a .so).
Propose to either
1) change the deployment component to search for ".so" on non-Mac and ".dylib" on Mac (easiest approach, just compile-time set the extension of interest), OR
2) add ".dylib" search as well as ".so" search on Mac (many more changes required).
Changing the deployer to simply not tack on the .so if it finds a .dylib extension, isn't that useful as it prevents the use of the same .xml file in both Linux and Mac settings (which we have).
Thoughts?
S