Feature #1080

Under Linux, load NeL drivers from a specific directory

Added by kervala almost 8 years ago. Updated almost 8 years ago.

Status:Closed Start date:08/27/2010
Priority:Normal Due date:
Assignee:kervala % Done:

100%
Category:OS: GNU/Linux
Target version:Version 0.8.0

Description

/usr/lib, /usr/local/lib, etc... directories are for libs which can be linked with a -l. NeL drivers are plugins, they have to be loaded dynamically with dlopen and there is a convention to put them in a subfolder. For example, mozilla/firefox plugins are in /usr/lib/mozilla.

So NeL drivers should be installed in /usr/lib/nel or /usr/local/lib/nel and loaded from there.

History

#1 Updated by kervala almost 8 years ago

  • Status changed from New to Assigned
  • Assignee set to kervala

#2 Updated by rti almost 8 years ago

As long as there are no .framework / .bundle etc things on Mac, this could be the way to do it on Mac as well...

#3 Updated by sfb almost 8 years ago

How would this work if we use .framework/.bundle on OSX? CPack is capable of generating these but I don't know what the advantage/disadvantage is...

#4 Updated by kervala almost 8 years ago

  • Status changed from Assigned to Resolved
  • Target version set to Version 0.8.0
  • % Done changed from 0 to 100

I set drivers to "MODULE" type so I don't know if it changes anything on Mac OS :s

Please fix things which need to be fixed under Mac OS :) Thanks.

As repository browser is not working anymore, you can see changes on :

http://ryzom.hg.sourceforge.net/hgweb/ryzom/ryzom/rev/143fa5a809c7

I basically changed SHARED to MODULE for drivers, added NL_DRIVER_PREFIX which specify where to find NeL drivers (it's defined in config.h because i don't want to polute GCC command line with a lot of -D ^^), in dru.cpp and sound_driver.cpp it adds this directory as alternate path to find the driver. I removed SOVERSION and VERSION from modules to have only one .so for each module and no symbolic link.

#5 Updated by rti almost 8 years ago

The change to MODULE made the drivers compile into .so files on Mac. So the dynamic loader needed an adjustment concerning the filename to use.

The file command shows some difference between the libraries and the modules, but I am not sure what makes the real difference between them.

rti@shilver ~ % file /usr/local/lib/libnel3d.dylib
/usr/local/lib/libnel3d.dylib: Mach-O 64-bit dynamically linked shared library x86_64
rti@shilver ~ % file /usr/local/lib/nel/libnel_drv_opengl.so
/usr/local/lib/nel/libnel_drv_opengl.so: Mach-O 64-bit bundle x86_64

So everything is fine now as long as it is ok to go the "unix-way" on Mac OS.

If we want more Mac-like stuff, the NeL libraries should be wrapped into .framework directories, containing libs and headers. The drivers might fit into .plugin folders (e.g. browser plugins like the flash player work that way) which again contain the library and some meta data. I'll create a separate issue for that.

#6 Updated by rti almost 8 years ago

btw, the change http://ryzom.hg.sourceforge.net/hgweb/ryzom/ryzom/rev/bc823c5889b0 for loading .so not .dylib :)

#7 Updated by kervala almost 8 years ago

Thanks a lot rti :)

It seems like MODULE changed something on Mac in the right way because "bundles" are plugins (see http://itk.org/Wiki/CMake:Bundles_And_Frameworks) :)

#8 Updated by rti almost 8 years ago

Yes, doing file on the library in a .plugin directory shows the same output like doing file on the new driver .so (see above)

#9 Updated by kervala almost 8 years ago

Applied in changeset r661.

#10 Updated by rti almost 8 years ago

Applied in changeset r666.

#11 Updated by kervala almost 8 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF