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