Dirk Reiners wrote: > Hi Patrick, > > On Fri, 2006-08-18 at 09:11 -0500, Patrick Hartling wrote: >> 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. > > Agreed. > >> 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. > > Did you try explicitly dlopen-ing an so that just contains the symbols > and see if that worked? If not and we would have to explicitly dlsym all > the possible symbols it would not be feasible.
No, I didn't try that. I could pursue that if you want to know the results, but it will take a bit longer than the simpler tests that I did. >> 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. > > Yeah, that doesn't sound good. > >> 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. > > I don't this as a good solution, honestly. Giving up link-time checks is > a big step, and giving up explicit construction makes for very > unreadable code. I agree. > I think the main motivation was to make it easier on users not to have > to know which libs are needed in the dependency chain. I don't really > see that as a big problem, as libs can be made to depend on other libs, > which just solves that automatically. In general, yes. I think that if there are going to be more arguments to pass to the linker to link an application, then there should be an easy, robust way to query those arguments. Having osg-config providing that information has worked pretty well in general, but as an sh script, it is not quite as easy to use on Windows as one might like. Using automatic linking on Windows would help with that, as would using a portable tool such as flagpoll (https://realityforge.vrsource.org/view/FlagPoll/) to query compiler and linker arguments along with other package metadata. -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
