Ok, got it...cheers.

On 13 August 2010 08:41, Josh Faust <jfaust@willowgarage.com> wrote:

> test_as_needed_so.cpp:
>
> #include <cstring>
> #include <cstdio>
>
> class Foo
> {
> public:
>   Foo()
>   {
>     printf("foo init\n");
>   }
>
>   ~Foo()
>   {
>     printf("foo deinit\n");
>   }
> };
>
> Foo foo;
>
> test_as_needed.cpp
> #include <cstdio>
>
> int main(int argc, char** argv)
> {
>   printf("main\n");
> }
>
>
>
> jfaust@bvu:~/scratch$ g++ test_as_needed_so.cpp -shared -fPIC -o
> libtest_as_needed_so.so
> jfaust@bvu:~/scratch$ g++ test_as_needed.cpp -o test_as_needed
> -ltest_as_needed_so
> jfaust@bvu:~/scratch$ ./test_as_needed
> foo init
> main
> foo deinit
>
> jfaust@bvu:~/scratch$ g++ test_as_needed.cpp -Wl,--as-needed -o
> test_as_needed -ltest_as_needed_so
> jfaust@bvu:~/scratch$ ./test_as_needed
> main
>
>
> If you use the variable it has to link it in... it's when there's some
> global initialization that causes side effects even if you're not explicitly
> referencing any symbols.  Not necessarily a problem, but something to look
> out for.
>
> Josh
>
> On Thu, Aug 12, 2010 at 4:13 PM, Daniel Stonier <d.stonier@gmail.com>wrote:
>
>>
>>
>> On 10 August 2010 02:32, Josh Faust <jfaust@willowgarage.com> wrote:
>>
>>>
>>>> Happy to hear that it works in general (would be pretty bad if it
>>>> didn't...).  I'm more concerned about whether we're currently
>>>> specifying everything completely, or unknowingly exploiting
>>>> overlinkage.
>>>>
>>>> I guess the only way to find out is to build and test everything with
>>>> that option included.
>>>>
>>>>
>>> I just did two quick tests:
>>>  1) .so that overrides a global symbol (strstr in this case)
>>>  2) .so with a global object that has a constructor/destructor
>>>
>>> #1 worked, #2 failed (the .so was removed).
>>>
>>> If #1 failed I'd say we can't default to it.  Not sure how important #2
>>> is, but it's something that could definitely cause problems that would be
>>> difficult to track down.
>>>
>>> Josh
>>>
>>
>> Josh, how did you produce result 2)? I just tested it here to be aware of
>> when it might break and couldn't reproduce the failure. It correctly
>> excludes/includes the library when I comment/uncomment the relevant usage of
>> the variable. Snippets below:
>>
>> LIBRARY HPP:
>>
>> namespace ecl {
>>
>> class A {
>> public:
>> A() : i(3) {}
>> ~A() {}
>> int i;
>> };
>> extern const A a;
>>
>> }
>>
>> LIBRARY CPP:
>>
>> namespace ecl {
>>
>> const A a;
>>
>> }
>>
>> MAIN CPP
>>
>> int main() {
>>     std::cout << "i: " << ecl::a.i << std::endl;
>>     return 0;
>> }
>>
>>
>>
>>
>>
>>
>> --
>> Phone : +82-10-5400-3296 (010-5400-3296)
>> Home: http://snorriheim.dnsdojo.com/
>> Yujin Robot: http://www.yujinrobot.com/
>> Embedded Control Libraries:
>> http://snorriheim.dnsdojo.com/redmine/wiki/ecl
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users@code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>


-- 
Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/
Yujin Robot: http://www.yujinrobot.com/
Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl