Dirk Reiners wrote: > Hi Allen, > > On Thu, 2006-08-17 at 21:34 -0500, Allen Bierbaum wrote: >> Having OpenSG do it internally. My (possibly naive) approach would be >> to scan a given plugin path and load all the .so/.dll files in that >> directory. This would be similar to how other systems do it so I think >> it could work. > > We have that one already, using OSG_LOAD_LIBS, OSG_PLUGIN_PATH and > OSG_PLUGIN_PATTERN. > >> Is there any way possible we could still use Geometry::create(). I >> guess this would really depend upon whether it is possible to compile an >> application that uses the interface of Geometry without it having to >> resolve the symbols at compile time.
When I was talking about this with Allen yesterday, I didn't think about
this aspect of things. That seems like a potential show-stopper problem to
me, but I am not a linker guru.
> Well, it would work for all objects that are explicitly linked to the
> application. I don't think the run-time linker would let you start a
> program without being able to resolve all symbols, but I might be wrong
> about this.
Yes, this is generally the case in my experience. Explicit references to
symbols in applications are supposed to be resolved at link time. Plug-ins
to C++ applications are best suited for accessing abstract interfaces where
specific symbol references are not needed and are instead resolved at run time.
> If it does let you, as long as you don't call any of the
> offending functions before osgInit is run (which you probably can't do
> anyway), you should be fine.
>
> To sum it up: could work, but would require support by the OS.
I tested linking an application with unresolved symbols on Red Hat
Enterprise Linux 4 x86_64, Fedora Core 4 i386, Windows XP (using Visual C++
7.1 and 8.0), FreeBSD 6.1-stable, and Mac OS X 10.4.7. With the right
additional options for the linker, I was able to create an executable
containing unresolved symbol references. The GNU linker, the Apple linker,
and the Visual C++ linker all require different options to make this work,
of course. The executable loaded, but it didn't run on any of them. It
crashed when trying to call the unresolved symbol, but it ran fine when the
unresolved symbol is not called. Hence, there is some hope that osgInit()
could save the day.
A different issue is that, on Windows, the linker outputs a warning that is
likely to make a lot of people nervous:
/out:test.exe
/force:unresolved
test.obj
test.obj : error LNK2019: unresolved external symbol "public: static class
MyClass * __cdecl MyClass::create(void)" ([EMAIL PROTECTED]@@[EMAIL PROTECTED])
referenced in function _main
test.exe : warning LNK4088: image being generated due to /FORCE option;
image may not run
There might be another option that can suppress this warning. Nevertheless,
in all cases, you're basically requiring users to give up link-time checks
that would catch missing library references or other simple mistakes that
lead to rather ugly crashes at run time.
>> As far as b), the method I was thinking of wouldn't need that (as far as
>> I can tell) because it would just load all the libraries that it can
>> find at startup time. There would be no dynamic searching of the
>> libraries that it needs for a given node type.
>
> OK.
>
>> As an aside, using something like "FCFactory::create("Geometry")" would
>> not really help the usability of OpenSG IMHO.
>
> Nope.
Unfortunately, this--or something like it--seems to me to be the most likely
way it would have to be implemented to avoid complexities when linking. Even
when reflection is built into a programming language, I have found it to be
cumbersome to use. Aside from writing unintuitive code, you are, of course,
giving up some compile-time and link-time checks that would otherwise catch
small typos and such. Nevertheless, I really like reflection and what it
provides at a high level, and OpenSG's use of reflective interfaces is a
beautiful thing. Getting down to the nuts and bolts of reflection, however,
usually requires writing code that isn't always pleasant.
-Patrick
--
Patrick L. Hartling | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2msw3 | http://www.infiscape.com/
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
