View Issue Details

IDProjectCategoryView StatusLast Update
0006897ScribusBuild Systempublic2008-07-09 19:08
Reportervince Assigned Tocbradney  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Platformi386OSNetBSDOS Versioncurrent (4.99)
Product Version1.3.5svn 
Fixed in Version1.3.5svn 
Summary0006897: Plugin load fails with undefined symbols (for all plugins)
DescriptionHi 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
TagsNo tags attached.
Patch

Activities

plinnell

2008-04-05 21:15

viewer   ~0019380

Reminder sent to: ringerc

Craig, Any ideas here ?

plinnell

2008-04-05 21:16

viewer   ~0019381

Can you give the compiler version and bsd equivalent of binuitls on BSD if it different ?

vince

2008-04-06 10:57

reporter   ~0019382

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.

ringerc

2008-04-06 17:09

reporter   ~0019385

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?)

vince

2008-04-06 18:25

reporter   ~0019388

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

vince

2008-04-06 19:29

reporter   ~0019394

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.

vince

2008-04-06 20:13

reporter   ~0019395

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

ringerc

2008-04-06 20:36

reporter   ~0019397

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.

ringerc

2008-04-06 20:41

reporter   ~0019398

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?

vince

2008-04-07 09:00

reporter   ~0019405

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.

plinnell

2008-04-09 09:12

viewer   ~0019425

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

eclypse

2008-04-10 14:22

reporter   ~0019433

Last edited: 2008-04-10 14:26

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 ;-)

ringerc

2008-04-13 11:20

reporter   ~0019465

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.

cbradney

2008-05-27 20:09

administrator   ~0019750

Can you please test with rev 12176 of 135svn? This patch is now in SVN.

Issue History

Date Modified Username Field Change
2008-03-29 16:23 vince New Issue
2008-04-05 21:15 plinnell Note Added: 0019380
2008-04-05 21:16 plinnell Note Added: 0019381
2008-04-06 10:57 vince Note Added: 0019382
2008-04-06 17:09 ringerc 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 ringerc Note Added: 0019397
2008-04-06 20:37 ringerc Severity block => major
2008-04-06 20:37 ringerc Status new => confirmed
2008-04-06 20:37 ringerc Projection none => minor fix
2008-04-06 20:37 ringerc Category Plug-ins => Build System
2008-04-06 20:41 ringerc Note Added: 0019398
2008-04-07 09:00 vince Note Added: 0019405
2008-04-09 09:12 plinnell 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 ringerc 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