From: <gf...@us...> - 2001-04-09 01:28:52
|
On Wed, Apr 04, 2001 at 05:26:23PM +1000, Peter Wang wrote: > I was actually talking about the statically linked bits of Allegro. > I'm not so sure any of this will work, though. I took a copy of > ex3d from my desktop machine (with libggi) and tried to run it on my > laptop (without libggi). The error message was: > > ./ex3d: error while loading shared libraries: libggi.so.2: cannot open shared object file: No such file or directory > > So the dependency is still there. ldd on the ex3d binary shows > libggi.so. ldd on the Allegro library does not. My system shows the same thing for the examples -- if I rename liballegro-3.9.35.so, ldd on an executable says it can't find that, but goes on to list all the dependency libraries. It doesn't do this for things you build yourself. It looks like the makefile still links the dependency libraries to the example programs etc -- I changed allegro-config to stop it doing that, but the example programs don't use this. The problem is here: makefile.dep: examples/ex3d$(EXE): $(OBJDIR)/ex3d$(OBJ) $(LIBALLEG) $(LINK) -o examples/ex3d$(EXE) $(OBJDIR)/ex3d$(OBJ) $(LINK_LIBALLEG) $(LIBS) which comes from here: ========================================================== diff -u -r1.1.1.1 deplexe.sh --- misc/deplexe.sh 2000/05/14 20:16:49 1.1.1.1 +++ misc/deplexe.sh 2001/04/08 22:05:34 @@ -55,7 +55,7 @@ # Program. echo "$dir/$name\$(EXE): \$(OBJDIR)/$name\$(OBJ) \$(LIBALLEG)" - echo " \$(LINK) -o $dir/$name\$(EXE) \$(OBJDIR)/$name\$(OBJ) \$(LINK_LIBALLEG) \$(LIBS)" + echo " \$(LINK) -o $dir/$name\$(EXE) \$(OBJDIR)/$name\$(OBJ) \$(LINK_LIBALLEG)" echo "" # Object file. =========================================================== > Also (on the one machine this time), I compiled a program using the > C-only library and tried to run it using the asm-enabled library. > The first symbol it complained about was _poly_scanline_gcol8, which > the asm-enabled library was expecting to exist in the binary. I > can't think of how to get around this one. I think there will be a lot of conflicts between C and asm versions of the library. In this case, that routine lives in the static part of the library, but this is empty for the C version of the library. So the executable had nothing linked into it here -- everything was dynamic. However in the running environment, the dynamic library was expecting the asm routines to have been statically linked. I wonder how far the plugin system goes towards solving these problems. I guess it won't fix this particular problem at all. It still leaves some problems with distributing binary versions of Allegro, too, but it does simplify that a lot. George -- Random project update: 06/03/2001: AllegroGL 0.0.10 released at http://allegrogl.sourceforge.net/ Six months' worth of changes, including Mingw32 support! |