View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006897 | Scribus | Build System | public | 2008-03-29 16:23 | 2008-07-09 19:08 |
| Reporter | vince | Assigned To | cbradney | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | i386 | OS | NetBSD | OS Version | current (4.99) |
| Product Version | 1.3.5svn | ||||
| Fixed in Version | 1.3.5svn | ||||
| Summary | 0006897: Plugin load fails with undefined symbols (for all plugins) | ||||
| Description | Hi there, when trying for the first time to run the 1.3.5svn version of Scribus, I found that no plugin would load: all report an undefined symbol, either _ZTI13UpdateMemento or _ZN14ScActionPlugin16staticMetaObjectE Well, I have checked a bit further. Both objects are (hopefully) defined in the scribus binary, one if of the WEAK symbol type, as readelf reveals: Symbol table '.symtab' contains 18824 entries: Num: Value Size Type Bind Vis Ndx Name 11236: 089bc8e0 8 OBJECT WEAK DEFAULT 15 _ZTI13UpdateMemento The other cannot be found by readelf, but nm locates it as being of a "read only" type: nm /usr/pkg/scribus135/bin/scribus | grep _ZN14ScActionPlugin16staticMetaObjectE 0896c714 R _ZN14ScActionPlugin16staticMetaObjectE I suspect that 'const ScActionPlugin::staticMetaObject () const', returning a const pointer on a const object is optimized away as a const value and directly assigned or inlined. I have no explanation for the other symbol, though. dlopen (…) in pluginmanager seems all right. Maybe a weak symbol cannot be associated at runtime with an undefined? I tried to cancel the SCRIBUS_API attribute but to no avail, so I guess (as readelf shows) this is not a symbol visibility issue. Any clue would be appreciated ;) Thx. Vincent | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
|
Reminder sent to: Craig, Any ideas here ? |
|
|
Can you give the compiler version and bsd equivalent of binuitls on BSD if it different ? |
|
|
Scribus 1.3.4 works perfectly well. I've tried to locate the same symbols, but they don't exist. There is a _ZN14ScActionPlugin16staticMetaObjectEv, it is undefined in plugins but of the 'T' (text) type in the main code, so there is no problem with dlopen (). gcc -v Using built-in specs. Target: i386--netbsdelf Configured with: /usr/src/tools/gcc/../../gnu/dist/gcc4/configure --enable-long-long --disable-multilib --enable-threads --disable-symvers --build=x86_64-unknown-netbsd4.99.52 --host=i386--netbsdelf --target=i386--netbsdelf --enable-__cxa_atexit Thread model: posix gcc version 4.1.3 20080202 prerelease (NetBSD nb1 20080202) This is the "standard" gcc as distributed with NetBSD (note that, owning to a bad feeling for the GPL v3, the future of GCC as the standard BSD C compiler is uncertain). BSD binutils are the same. I wonder if this is not caused by using cmake instead of libtool. Rpath issue? It would be maybe interesting to know what nm and readelf report on a working (Linux?) box. V. |
|
|
OK, those symbols are: _ZTI13UpdateMemento : typeinfo for UpdateMemento _ZN14ScActionPlugin16staticMetaObjectE : ScActionPlugin::staticMetaObject The fact that there's no typeinfo for UpdateMemento is VERY weird. Maybe the class is not being built or not being linked into the executable? Can you see updatemanager.o in the list of object files in the Scribus executable or see it on the linker command line? If you examine updatemanager.o with nm does it contain the _ZTI13UpdateMemento symbol? I can't see it being built with -fno-rtti, and that's the only other cause I can think of. The other symbol you're having issues with is part of the Qt metaobject system, and is defined by `moc'. What Qt4 version are you using? What is the output of `moc -v' ? " I suspect that 'const ScActionPlugin::staticMetaObject () const', returning a const pointer on a const object is optimized away as a const value and directly assigned or inlined. " This is not permitted unless ScActionPlugin is declared `static' or is in an anonymous namespace. In C++, even if it has private accessibility it must be visible to the linker unless special linker hints like __attribute__ ((visibility("hidden"))) are used. GENERAL "SLEDGEHAMMER FIX" QUESTIONS: Have you done a clean rebuild of Scribus from a new external build tree? (I recommend always using an out-of-tree build), and installed it into a new location that does not contain any exiting files (think: /usr/local/scribus135) ? Have you verified using ldd or similar that the plugins being loaded are in fact the ones that were built for this version of Scribus? What linker and version are you using? (GNU ld or something else?) |
|
|
Hello ! Here it is: nm updatemanager.o | grep Memento 00000000 T _ZN13UpdateManager13requestUpdateEP13UpdateManagedP13UpdateMemento 000000cc T _ZN13UpdateMementoD0Ev 000000e0 T _ZN13UpdateMementoD1Ev 000000f0 T _ZN13UpdateMementoD2Ev 00000000 W _ZN5QHashI5QPairIP13UpdateManagedP13UpdateMementoE15QHashDummyValueE13detach_helperEv 00000000 W _ZN5QHashI5QPairIP13UpdateManagedP13UpdateMementoE15QHashDummyValueE13duplicateNodeEPN9QHashData4NodeEPv 00000000 W _ZN5QHashI5QPairIP13UpdateManagedP13UpdateMementoE15QHashDummyValueE8freeDataEP9QHashData 00000000 W _ZNK5QHashI5QPairIP13UpdateManagedP13UpdateMementoE15QHashDummyValueE8findNodeERKS5_Pj 00000000 V _ZTI13UpdateMemento 00000000 V _ZTS13UpdateMemento 00000000 V _ZTV13UpdateMemento As I said before, I have three weak ("V") UpdateMemento objects, of different types it seems. Readelf shows more interesting things: readelf -a updatemanager.o | grep UpdateMemento [...] COMDAT group section `.group' [_ZTV13UpdateMemento] contains 1 sections: [ 24] .rodata._ZTV13UpdateMemento COMDAT group section `.group' [_ZTS13UpdateMemento] contains 1 sections: [ 29] .rodata._ZTS13UpdateMemento COMDAT group section `.group' [_ZTI13UpdateMemento] contains 1 sections: [ 30] .rodata._ZTI13UpdateMemento 000000d4 00002801 R_386_32 00000000 _ZTV13UpdateMemento 000000e8 00002801 R_386_32 00000000 _ZTV13UpdateMemento 000000f8 00002801 R_386_32 00000000 _ZTV13UpdateMemento [...] Relocation section '.rel.rodata._ZTV13UpdateMemento' at offset 0x1ca0 contains 3 entries: 00000004 00003501 R_386_32 00000000 _ZTI13UpdateMemento 00000008 00002a01 R_386_32 000000e0 _ZN13UpdateMementoD1Ev 0000000c 00002701 R_386_32 000000cc _ZN13UpdateMementoD0Ev Relocation section '.rel.rodata._ZTI13UpdateMemento' at offset 0x1cc8 contains 2 entries: 00000004 00003801 R_386_32 00000000 _ZTS13UpdateMemento [...] 39: 000000cc 18 FUNC GLOBAL DEFAULT 11 _ZN13UpdateMementoD0Ev 40: 00000000 16 OBJECT WEAK DEFAULT 24 _ZTV13UpdateMemento 42: 000000e0 14 FUNC GLOBAL DEFAULT 11 _ZN13UpdateMementoD1Ev 43: 000000f0 14 FUNC GLOBAL DEFAULT 11 _ZN13UpdateMementoD2Ev 53: 00000000 8 OBJECT WEAK DEFAULT 30 _ZTI13UpdateMemento 56: 00000000 16 OBJECT WEAK DEFAULT 29 _ZTS13UpdateMemento Definitely, those UpdateMemento symbols are treated as readonly objects. As for the moc: grep moc CMakeCache.txt //The moc executable QT_MOC_EXECUTABLE:FILEPATH=/usr/pkg/qt4/bin/moc /usr/pkg/qt4/bin/moc -v Qt Meta Object Compiler version 59 (Qt 4.3.2) For the rest, all the plugins and executable are placed in a separate tree (in fact /usr/pkg/scribus135), and the error message is unambiguous: Impossible de trouver l'extension: /usr/pkg/scribus135/lib/scribus/plugins//libsvgexplugin.so: Undefined symbol "_ZN14ScActionPlugin16staticMetaObjectE" (symnum = 61) (sorry for the French — translation is just "impossible to find plug-in"). Note that ldd reports no missing libs: ldd /usr/pkg/scribus135/lib/scribus/plugins//libsvgexplugin.so /usr/pkg/scribus135/lib/scribus/plugins//libsvgexplugin.so: -lz.1 => /usr/lib/libz.so.1 -lfreetype.6 => /usr/pkg/lib/libfreetype.so.6 -lexpat.1 => /usr/pkg/lib/libexpat.so.1 -lfontconfig.1 => /usr/pkg/lib/libfontconfig.so.1 -lm.0 => /usr/lib/libm387.so.0 -lm.0 => /usr/lib/libm.so.0 -lglitz.1 => /usr/pkg/lib/libglitz.so.1 -lpng12.0 => /usr/pkg/lib/libpng12.so.0 -lXau.6 => /usr/pkg/lib/libXau.so.6 -lXdmcp.6 => /usr/pkg/lib/libXdmcp.so.6 -lX11.6 => /usr/pkg/lib/libX11.so.6 -lXrender.1 => /usr/pkg/lib/libXrender.so.1 -lpthread.0 => /usr/lib/libpthread.so.0 -lcairo.2 => /usr/pkg/lib/libcairo.so.2 -lstdc++.6 => /usr/lib/libstdc++.so.6 -lgcc_s.1 => /usr/lib/libgcc_s.so.1 Finally: ld -v GNU ld version 2.16.1 Vincent |
|
|
Somebody on one netbsd list has suggested it might be caused by a missing -E flag at link time. In fact, I had no "-E" flag in the CMakeCache.txt so I added one at the ad hoc place. Will try to see what happens. |
|
|
Ok, that's it. The default CMake config fails to add "-Wl,-E" as default linking flags for g++, wherefore some symbols remain hidden. It is fixed by ensuring this line in CMakeCache.txt: CMAKE_EXE_LINKER_FLAGS:STRING=-Wl,-E Sorry for the noise, but it might be worth adding a check in the initial configuration procedure. Vincent |
|
|
Re -E: Based on the linker documentation that makes sense, and it's probably something we can safely add all platforms that use GNU ld. -fvisibility=hidden should still result in an executable where only explicitly visible symbols are exported if set, so if we're worried about symbol table size we can just start building with -fvisibility=hidden on supporting compilers by default. It's interesting that linking back to the executable has generally worked fine on most platforms in the absence of this flag. We don't use a version script (it's a nightmare to do so with C++) so the linker should've been eliminating unreferenced symbols from the symbol table on all platforms. Time for a CMakeLists update, I guess. As for the nature of the symbols: " 00000000 V _ZTI13UpdateMemento 00000000 V _ZTS13UpdateMemento 00000000 V _ZTV13UpdateMemento As I said before, I have three weak ("V") UpdateMemento objects, of different types it seems." craig@wallace:~$ c++filt <<__END__ > 00000000 V _ZTI13UpdateMemento > 00000000 V _ZTS13UpdateMemento > 00000000 V _ZTV13UpdateMemento > __END__ 00000000 V typeinfo for UpdateMemento 00000000 V typeinfo name for UpdateMemento 00000000 V vtable for UpdateMemento craig@wallace:~$ ... so they're the typeinfo descriptor, typeinfo name string, and vtable respectively, all for the UpdateMemento type. |
|
|
Reminder sent to: cbradney This bug has been identifed as an issue with the build system - we need to use -export-dynamic when linking with GNU ld to reliably ensure that symbols, including all SCRIBUS_API symbols, are actually exported in the symbol table. No idea if other linkers accept the same argument, so we might have to test for GNU ld. Or, of course, just not care and assume GNU ld (*gasp*) on UNIX platforms. Any idea if CMake has a built-in variable for linker type like the (GCC) and (MSVC) compiler-type variables? |
|
|
I am also a bit surprised that this passed unnoticed. Maybe the Linux ld or elf loader is more relaxed than the NetBSD one (e.g., it might assume -E whether the flag is present or not). Anyhow, if you want to carry further tests related to visibility attributes, I'll be delighted to help you. I don't think assuming gnu ld is a good thing, especially with the uncertain future of GNU libtools on BSD machines (due to GPLv3 resenting). The default compiler and loader might change in a forseeable future. |
|
|
Seeing similar issues with cmake build on Suse 10.3 with 13312svn: /opt/13312/bin/scribus Cannot find plugin: /opt/13312/lib/scribus/plugins//libsvgimplugin.so: undefined symbol: _ZN8ScPlugin19newPrefsPanelWidgetEP7QWidgetRP10PrefsPanelR7QStringR7QPixmap Cannot find plugin: /opt/13312/lib/scribus/plugins//libsvgexplugin.so: undefined symbol: _ZN8ScPlugin19newPrefsPanelWidgetEP7QWidgetRP10PrefsPanelR7QStringR7QPixmap Cannot find plugin: /opt/13312/lib/scribus/plugins//libscriptplugin.so: undefined symbol: _ZTI10PrefsPanel Cannot find plugin: /opt/13312/lib/scribus/plugins//libscribusshortwords.so: undefined symbol: _ZN14ScActionPlugin3runEP9QIODevice Cannot find plugin: /opt/13312/lib/scribus/plugins//libscribusexportpixmap.so: undefined symbol: _ZN8ScPlugin19newPrefsPanelWidgetEP7QWidgetRP10PrefsPanelR7QStringR7QPixmap Cannot find plugin: /opt/13312/lib/scribus/plugins//libsaveastemplateplugin.so: undefined symbol: _ZN8ScPlugin19newPrefsPanelWidgetEP7QWidgetRP10PrefsPanelR7QStringR7QPixmap Cannot find plugin: /opt/13312/lib/scribus/plugins//liboodrawimp.so: undefined symbol: _ZN8ScPlugin19newPrefsPanelWidgetEP7QWidgetRP10PrefsPanelR7QStringR7QPixmap Cannot find plugin: /opt/13312/lib/scribus/plugins//liboldscribusformat.so: undefined symbol: _ZN8ScPlugin19newPrefsPanelWidgetEP7QWidgetRP10PrefsPanelR7QStringR7QPixmap Cannot find plugin: /opt/13312/lib/scribus/plugins//libnewfromtemplateplugin.so: undefined symbol: _ZN8ScPlugin19newPrefsPanelWidgetEP7QWidgetRP10PrefsPanelR7QStringR7QPixmap Cannot find plugin: /opt/13312/lib/scribus/plugins//libimportps.so: undefined symbol: _ZN8ScPlugin19newPrefsPanelWidgetEP7QWidgetRP10PrefsPanelR7QStringR7QPixmap Cannot find plugin: /opt/13312/lib/scribus/plugins//libfontpreview.so: undefined symbol: _ZN8ScPlugin19newPrefsPanelWidgetEP7QWidgetRP10PrefsPanelR7QStringR7QPixmap Cannot find plugin: /opt/13312/lib/scribus/plugins//libcolorwheel.so: undefined symbol: _ZN8ScPlugin19newPrefsPanelWidgetEP7QWidgetRP10PrefsPanelR7QStringR7QPixmap Cannot find plugin: /opt/13312/lib/scribus/plugins//libbarcodegenerator.so: undefined symbol: _ZN8ScPlugin19newPrefsPanelWidgetEP7QWidgetRP10PrefsPanelR7QStringR7QPixmap |
|
|
When i built scribus in FreeBSD, i got same thing... so i stopped it all because i was bored ! But, i noticed that there's a pkg that's using CMAKE and Qt4. I did not try to follow this "example" for Scribus. It was texmaker. http://www.freebsd.org/cgi/ports.cgi?query=texmaker&stype=all Important I noticed same thing also when i built scribus 1.3.3.12svn. If i didn't use the "standard installation" ... ie /usr/ports/print/scribus I hope you could do something good ;-) |
|
|
For now, we might as well do something like this: IF (GCC AND NOT WIN32) # Use the -E / --export-dynamic flag to ensure that symbols in the Scribus # binary are in the public symbol table for plugins. The symbols must also # be set as SCRIBUS_API if we're building with -fvisibility=hidden . # Should fix bug 6897 . SET_TARGET_PROPERTIES(scribus PROPERTIES LINK_FLAGS -Wl,-E) ENDIF (GCC AND NOT WIN32) That'll break if people are using gcc with a non-GNU linker that doesn't understand -E , but I'm not sure that'll be too common. I'd rather not commit it since I'm not at a Linux box right now. |
|
|
Can you please test with rev 12176 of 135svn? This patch is now in SVN. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-03-29 16:23 | vince | New Issue | |
| 2008-04-05 21:15 |
|
Note Added: 0019380 | |
| 2008-04-05 21:16 |
|
Note Added: 0019381 | |
| 2008-04-06 10:57 | vince | Note Added: 0019382 | |
| 2008-04-06 17:09 |
|
Note Added: 0019385 | |
| 2008-04-06 18:25 | vince | Note Added: 0019388 | |
| 2008-04-06 19:29 | vince | Note Added: 0019394 | |
| 2008-04-06 20:13 | vince | Note Added: 0019395 | |
| 2008-04-06 20:36 |
|
Note Added: 0019397 | |
| 2008-04-06 20:37 |
|
Severity | block => major |
| 2008-04-06 20:37 |
|
Status | new => confirmed |
| 2008-04-06 20:37 |
|
Projection | none => minor fix |
| 2008-04-06 20:37 |
|
Category | Plug-ins => Build System |
| 2008-04-06 20:41 |
|
Note Added: 0019398 | |
| 2008-04-07 09:00 | vince | Note Added: 0019405 | |
| 2008-04-09 09:12 |
|
Note Added: 0019425 | |
| 2008-04-10 14:22 | eclypse | Note Added: 0019433 | |
| 2008-04-10 14:26 | eclypse | Note Edited: 0019433 | |
| 2008-04-13 11:20 |
|
Note Added: 0019465 | |
| 2008-05-27 20:09 | cbradney | Note Added: 0019750 | |
| 2008-07-08 17:59 | cbradney | Status | confirmed => resolved |
| 2008-07-08 17:59 | cbradney | Fixed in Version | => 1.3.5svn |
| 2008-07-08 17:59 | cbradney | Resolution | open => fixed |
| 2008-07-08 17:59 | cbradney | Assigned To | => cbradney |
| 2008-07-09 19:08 | cbradney | Status | resolved => closed |
