You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
component: component1 | priority: major | resolution: fixed
2011-09-07 14:00:25: @greghudson created the issue
libverto modules can be used as dynamically loaded objects or as directly linked libraries. They export module-specific symbols like verto_libev_default(), but also a fixed-named data symbol verto_module_table. Trying to link against two module libraries (perhaps one by the application and another by a subsidiary library which uses a private event loop) would result in a symbol conflict.
Verbally, Nathaniel has suggested that the module table symbol name will be changed to include the module name. This will require deducing the module name from the pathname in verto.c:do_load_dir().
The text was updated successfully, but these errors were encountered:
Issue migrated from trac ticket # 5
component: component1 | priority: major | resolution: fixed
2011-09-07 14:00:25: @greghudson created the issue
libverto modules can be used as dynamically loaded objects or as directly linked libraries. They export module-specific symbols like verto_libev_default(), but also a fixed-named data symbol verto_module_table. Trying to link against two module libraries (perhaps one by the application and another by a subsidiary library which uses a private event loop) would result in a symbol conflict.
Verbally, Nathaniel has suggested that the module table symbol name will be changed to include the module name. This will require deducing the module name from the pathname in verto.c:do_load_dir().
The text was updated successfully, but these errors were encountered: