Re: building a library using gtk+

[Dov Kruger <Dov Kruger stevens edu>]

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.

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.

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?

Thanks