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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list