Re: building a library using gtk+

["Brian J. Tarricone" <bjt23 cornell edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5/17/2006 11:06 AM, Dov Kruger wrote:
> Since originally posting this question, I've used the linker to try to
> create a dll. ar just assembles a number of .o files, I don't believe it
> resolves any symbols which is useless to me.
>
> So, I did
>
> ld -dll -o libglpp $(OBJ3) GLPPmain.o -L/opt/lib -lftgl -lgtk-x11-2.0
> -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0
> -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -L/usr/X11R6/lib
> -L/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/ -lstdc++ -lGL -lGLU
> -lgtkgl-2.0
>
> And it works except for
> ld: warning: cannot find entry symbol _start; defaulting to 0804ab94
> Viewer.o(.text+0x10ad): In function
> `__static_initialization_and_destruction_0':
> /usr/include/c++/3.2.3/iostream:63: undefined reference to
> `__dso_handle'
> Controller.o(.text+0x961): In function
> `__static_initialization_and_destruction_0':
> /usr/include/c++/3.2.3/iostream:63: undefined reference to
> `__dso_handle'
> Style.o(.text+0xb95): In function
> `__static_initialization_and_destruction_0':
> /home2/dkruger/dev/GLPP/core/Style.cc:4: undefined reference to
> `__dso_handle'
> Style.o(.text+0xbcb):/home2/dkruger/dev/GLPP/core/Style.cc:5: undefined
> reference to `__dso_handle'
> ECOMModelGrid.o(.text+0x1e1b): In function
> `__static_initialization_and_destruction_0':
> /usr/include/c++/3.2.3/iostream:63: undefined reference to
> `__dso_handle'
> GLPPmain.o(.text+0x7e5):/usr/include/c++/3.2.3/iostream:63: more
> undefined references to `__dso_handle' follow
> make: *** [libglpp.a] Error 1
>
>
> Please don't get hung up on the command line, which I am using only for
> test purposes. I can't use `pkg-config ...` with ld because it emits
> arguments suitable for the compiler, but:
>
> g++ `pkg-config ...`
>
> will presumably call the linker the same way with the right arguments. I
> just have to learn how to generate a .so from g++ as opposed to ld,
> where it was very clearly documented.

Right, you don't want to use the linker directly.  Something like this
should work:

g++ -shared -o libglpp.so $(OBJ3) GLPPmain.o $(GTK_LIBS) $(GTKGL_LIBS) \
    $(OPENGL_LIBS) $(WHATEVER_OTHER_LIBS)

Where you've presumably filled in all the *_LIBS vars with the
appropriate pkg-config calls, or just lists of libraries that don't
change.  Note that you should *not* manually link in libstdc++ here.
g++ will do that for you.

Now, this won't check for unresolved symbols.  On linux, shared
libraries are allowed to have unresolved symbols (at compile/link time,
anyway; not at runtime in general).  According to the 'ld' manpage, what
you want here is the --no-allow-shlib-undefined option.  To have g++
pass it to the linker, you'd pass '-Wl,--no-allow-shlib-undefined' to
g++.  I've never actually tried this, so I can't guarantee it will work.

If you need to do a manual check for unresolved symbols, an inspection
of the output of 'ldd -r -v libglpp.so' will tell you.

Really, I think you're best off compiling your .o files with -Wall and
making sure you're not calling nonexistant functions by examining
warnings.  That's the best way to avoid unresolved symbols due to typos,
etc.

(FYI, the '-dll' option you're using above is specific to x86 PE
executables, i.e., win32.)

> The point here is to build a pre-linked file so that I don't have to
> resolve all the references. This will dramatically speed the build of
> applications that are layered on a basic toolkit but use only one API
> (OpenGL) and do not use any gtk stuff, even though the core opens a gtk
> window and sets it up.

Will it really speed things up that much?  We're talking about a shared
library here that consists of only 7 object files, linked to a
relatively small number of shared libraries.  Unless you're compiling on
really old systems, the speed decrease should be minimal.

The reason I'd say building a shared library here would be so
application developers don't need to have copies of those 7 object
files, and you can also hide the internals of how you do things and
change them at will.

On a side note, why are you using gtk at all here?  It's pretty trivial
to open a simple window with xlib, and (presumably) associate it with an
opengl context.

> There is no reason to suppose that this approach is any less portable
> than the other, since the library can be built by dependency just as the
> rest of the code is. If the libraries were to change, my interface
> library should change, but I would have the same problem if the gtk
> libraries on the system were to change -- every program that calls them
> would potentially have the same dependency problem as the library,
> right?

Well, this approach isn't portable in the sense that if you link the
library on one machine, and copy it to another non-identical machine,
you could have problems.  Since you're using g++, systems with different
versions of libstdc++, or different versions of the compiler, would
probably cause imcompatibilities.

        -brian


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)

iD8DBQFEa76k6XyW6VEeAnsRArVuAKDI2JkPMpjGOTSCU9giDqm/RfIjeACcClUr
5szCIozLjaLPh8sCs8Wv/7s=
=8BlU
-----END PGP SIGNATURE-----