From: <jc...@fe...> - 2003-02-10 15:17:44
|
On Monday 10 February 2003 07:13, Rafael Laboissiere wrote: | * Maurice LeBrun <mj...@ga...> [2003-02-09 21:13]: | > I've not been following the discussion very closely, but does this | > mean that the code currently loads all dynamic drivers at startup | > time? If true, this seems against the spirit of dynamic drivers, | > and adds unnecessarily to the memory used by the application. | | This is what I thought at the beginning and this is why I proposed | the alternative design with the <driver>.rc files. However here is | what Joao wrote some days ago: | | * Jo=E3o Cardoso <jc...@fe...> [2003-02-07 14:51]: | > Your concerns that dlopen() would load all libraries that a driver | > needs does not apply, as this would only happens if some drivers | > code is executed, which is not the case. As libtool's info says: | > | > "Unresolved symbols in the module are resolved using | > its dependency libraries" | > | > As the symbols you are looking for are in the modules, no further | > loading will occur. Further, the libtool docs says that RTLD_LAZY is used when dlopen() is=20 effectively called. But one thing is what the docs says, the other what is done. What valgrind reports (in the attached program) is that libs are loaded:=20 =2E.. =3D=3D20614=3D=3D discard syms in /usr/lib/libjpeg.so.62.0.0 due to munma= p() =2E.. This seems to indicate that libjpeg was loaded, and latter unloaded,=20 even if not used, i.e., no code from it was executed and no symbol=20 belonging to it requested. But the dlopen() man page also says: If the library exports a routine named _init, then that code is executed before dlopen returns. and: [jcard@feup] nm -p /usr/lib/libjpeg.so | fgrep _init 0001aaa0 T jpeg_mem_init 00001fd4 T _init a _init function is defined in the library, meaning that it must be=20 executed. This must also happens for other libraries, as valgrind gives=20 the same kind of warning for other libraries. Of course on most systems the libraries are not loaded, as they are=20 already loaded by the several programs the user is working with, but=20 there are of course exceptions. Back to the drivers.rc solution, Rafael. The attached program also shows that the bug we found does not seems to=20 be in the libtool library, but in the system's libdl, as the program=20 calls dl*() directly. Joao | | I hope that this is true for all architectures. | | At any rate, as Alan pointed out, in the current design the driver | moudles should be dlclosed after the plD_DEVICE_INFO_<dirver> | variable is obtained. |