| Re: [AD] Compiling errors with Allegro 3.9.29 shared/debug version. |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Mon, Dec 13, 1999 at 11:01:31PM +0000, Shawn Hargreaves wrote:
> > lib/unix/liballd.so.3: undefined reference to `SEQ_PGM_CHANGE'
> > make: *** [tests/test] Error 1
>
> I don't get this either: both those dynamic symbols come from imisc.s, but
> you can't be missing that completely or it would also be complaining about a
> missing _stub_bank_switch, _do_stretch, and _blender_trans24. I can only
> think that the missing symbol is confusing it here.
We don't seem to have `-Werror' turned on, so if it were a
missing #define in a header file it would perhaps have been
taken as an implicit declaration without him noticing. This
error does not occur on my system.
> We do have a dependency problem to do with shared libs, though: if you
> enable share+debug programs, make clean, and then make tests/test, the
> dependencies create the .so files in lib/unix, but nothing has generated the
> liballd.a which the test program then tries to link with. George? Help! I
> don't understand how any of this stuff works: do I need to learn it, or do
> you have any idea what is going on here?
You can learn it if you want to, but I do know what's going on.
:) I don't think you meant `liballd.a' though -- if you're
working entirely with shared libraries, there shouldn't be a
liballd.a at all.
What we get is the real shared library (liballd-3.9.29.so), a
link to it which exists mostly for the dynamic loader's use
(liballd.so.3), the static library containing all the asm code
(liballd_nonshared.a), and a script tying it all together
(liballd.so). That script is what's explicitly linked on the
linker command line, and it pulls in the link and the static
library.
Maybe all we need to do is mark its dependencies properly, so
that it actually does force the static library to be compiled.
The change is simple, patch attached -- it seems to work. I
probably forgot to do this when I added the separate nonshared
library -- when I saw this email, I was surprised it bothered
to make anything at all. :)
Note that to run the tests/examples without installing the
shared library, you have to explicitly tell ldd where to look:
~/allegro/all3929/tests$ LD_LIBRARY_PATH=../lib/unix ./test
Incidentally, the normal way is for `liballd.so' to be a symlink
to one of the other two (doesn't matter which). We do it
differently because we need the static library; I just copied
the way libc.so works.
> A few other observations about shared libs:
>
> I installed the RPM version on my machine at work today, and then tried
> building SPEED, which didn't work using -lalleg, although it was ok when I
> changed that to use allegro-lib.
Yes, I mentioned this a while ago (that the shared library
scripts aren't including the dependency libraries), but never
got around to fixing it. Sorry!
> I don't have a problem with that: in fact
> it might well be worth phasing out the linker script hackery altogether in
> favour of only using allegro-lib, but if so we can simplify the linker
> scripts a lot, and should remove -lalleg from the docs. If you do want to
> keep -lalleg working, though, there is a problem using it with shared libs
> at the moment, at least in the form that the RPM installs.
OK; as I told you earlier, my latest preference is for
allegro-lib to just output:
-lX11 -lXext ....
and for people to write:
-lalleg `allegro-lib`
But it's all just another way to do the same thing -- we could
put everything into allegro-lib. After a brief look, it needs a
little adjustment -- because of the possibility of
cross-dependence between the shared and unsharable bits of the
library, we need a group statement there (e.g. `-(' and `-)').
> I'm still confused about what happens when you install both shared and
> static libs at the same time. If you only install one or the other,
> allegro-lib alone will select the version you installed, right?
Wrong at present -- it needs fixing. When it's generated we
need to make it default properly (to the only thing we're
building, or to whichever we decide (shared?) if we build both).
Personally I do think it should default in the same direction as
the linker. But see the next section...
> And if you
> install both, it uses the static ones unless you specify the shared option
> to allegro-lib? If that's how it works, it seems cool to me (although I need
> to update readme.uni to make this more clear), but it's still a mess when
> you try to link directly with the libs. I guess I'm thinking that it would
> be cleaner if we got rid of all that, and used allegro-lib exclusively.
I disagree about where the mess is. :) Linking directly with
the shared lib is broken right now, but can easily be fixed. To
me the mess is in how allegro-lib is meant to know whether it's
a static or shared link. It is unusual for someone to ask for a
static link with `-static' though (which is the only time this
matters).
I have two suggestions -- two different directions we can go in,
apart from using the old linker script system (which is less
portable). Either (a) `allegro-lib' just outputs the dependency
linking directives, and people have to write "-lalleg
`allegro-lib`". Or (b) `allegro-lib' takes care of everything.
(b) is what you were talking about, and it works fine but gets
awkward when both shared and static libraries are installed. If
we go with this system, I think in that case allegro-lib should
default to linking shared, and have a `static' option which
should be specified if `-static' is on the linker command line.
(a) is what I suggested yesterday I think. The `-lalleg' gets
handled by the linker as usual, either linking `liballeg.a'
(currently called `liballeg_backend.a', but that's redundant),
or trying to link `liballeg.so' which remains a linker
script in this system. This script links in the shared and
unsharable parts of the library. Then `allegro-lib` follows
that on the command line to link in the dependencies. In this
system, `allegro-lib' doesn't need to know whether we're linking
shared or static, and it doesn't need to know whether it's a
release, debug or profiling build -- that's chosen by the
library name used.
The reason I find (a) so simple is probably because it doesn't
even involve working out whether we're building both types of
library, when we generate the script -- the script just says
`echo $*'. And the reason I find (b) uncomfortable is that it
does need to know this, in order to default properly, and it
also needs to support the `static' switch to override the
default... it feels a bit messy. It is doable though.
> Why is the linker commandline being passed -O3 -ffast-math
> -fomit-frame-pointer, while linking debug programs? Those aren't linker
> switches at all, let alone debug ones :-)
Hmm. :) Another patch attached...
> I think the default configure option should be only shared libs and
> programs, with static linking only enabled if you explicitly request it.
> Anyone got a problem with that? Saves a _lot_ of disk space :-) At the
> moment it looks like the RPM versions are installing both shared and static
> libs: is there any reason for that, or couldn't they also always be shared
> unless told otherwise?
I'm not sure why I did that. :) They ought to just do whatever
the configure default ends up being, and I agree that should be
shared libraries.
I've attached two patches to this email -- the first fixes
deplib.sh (sorting out the dependency problem) and makefile.in
(sorting out the linker command line mistake), and the second
implements (a). I would do one for (b) as well but I'm not in
the right sort of mood. :) Facing another day in the office,
this time without any chance of being paid -- already been paid
for this, six months ago... Is it a general fact that when
you've already been paid for something you totally lose interest
in it? :)
George
diff -urN all3929-0/makefile.in all3929-1/makefile.in
--- all3929-0/makefile.in Tue Dec 14 01:59:01 1999
+++ all3929-1/makefile.in Tue Dec 14 01:59:37 1999
@@ -63,7 +63,7 @@
CPPFLAGS = @CPPFLAGS@
LDFLAGS = @LDFLAGS@
COMPILE = $(CC) $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS)
-LINK = $(CC) $(CFLAGS) $(LDFLAGS)
+LINK = $(CC) $(LDFLAGS)
CFLAGS = @CFLAGS@
ALLEGRO_DEBUG_CFLAGS = @ALLEGRO_DEBUG_CFLAGS@
diff -urN all3929-0/misc/deplib.sh all3929-1/misc/deplib.sh
--- all3929-0/misc/deplib.sh Tue Dec 14 01:53:21 1999
+++ all3929-1/misc/deplib.sh Tue Dec 14 01:54:28 1999
@@ -30,11 +30,11 @@
echo "\$(LIBDIR)/${soname}: \$(LIBDIR)/${sharelib}"
echo " cd \$(LIBDIR) ; ln -sf ${sharelib} ${soname}"
echo ""
- echo "\$(LIBDIR)/${link}: \$(LIBDIR)/${soname}"
+ echo "\$(LIBDIR)/${link}: \$(LIBDIR)/${soname} \$(LIBDIR)/${unsharelib}"
echo " \$(mksofile) \$(LIBDIR) ${link} ${soname} ${unsharelib}"
echo ""
echo "\$(LIBDIR)/${unsharelib}: ${unshareobj}"
- echo " rm -f ${unsharelib}"
+ echo " rm -f \$(LIBDIR)/${unsharelib}"
echo " \$(AR) rvs \$(LIBDIR)/${unsharelib} ${unshareobj}"
}
diff -urN all3929-1/makefile.in all3929-2/makefile.in
--- all3929-1/makefile.in Tue Dec 14 01:59:37 1999
+++ all3929-2/makefile.in Tue Dec 14 02:12:45 1999
@@ -50,7 +50,6 @@
mkinstalldirs = $(SHELL) $(srcdir)/misc/mkdirs.sh
mksofile = $(SHELL) $(srcdir)/misc/mksofile.sh
-mkfrontend = $(SHELL) $(srcdir)/misc/mkfrontend.sh
mkldscript = $(SHELL) $(srcdir)/misc/mkldscript.sh
CONFIG_H = include/allegro/alunixac.h
@@ -247,8 +246,7 @@
@for l in alleg alld allp; do \
if test -f $(LIBDIR)/lib$${l}.a; then \
echo Installing $(LIBDIR)/lib$${l}.a to $(libdir); \
- $(INSTALL_DATA) $(LIBDIR)/lib$${l}.a $(libdir)/lib$${l}_backend.a; \
- $(mkfrontend) $(libdir) $${l} "$(LIBS)" "@ALLEGRO_XWINDOWS_LIBDIR@"; \
+ $(INSTALL_DATA) $(LIBDIR)/lib$${l}.a $(libdir)/; \
fi; \
done
@for l in alleg alld allp; do \
diff -urN all3929-1/misc/mkfrontend.sh all3929-2/misc/mkfrontend.sh
--- all3929-1/misc/mkfrontend.sh Sun Dec 12 21:51:24 1999
+++ all3929-2/misc/mkfrontend.sh Thu Jan 1 01:00:00 1970
@@ -1,19 +0,0 @@
-#!/bin/sh
-# mkfrontend -- creates the .a file for an Allegro library, pulling
-# in the corresponding backend and all required libs
-#
-# Usage: mkfrontend libdir stem extra_libs extra_lib_dirs
-
-rm -f $1/lib$2.a
-
-cat > $1/lib$2.a << EOF
-/* GNU ld script
- This script links in the backend library along with any required
- support libraries (-lm, -lX11, -lvga, etc) */
-EOF
-
-if test $4 != ""; then
- echo "SEARCH_DIR ( $4 )" >> $1/lib$2.a
-fi
-
-echo "GROUP ( lib$2_backend.a $3 )" >> $1/lib$2.a
diff -urN all3929-1/misc/mkldscript.sh all3929-2/misc/mkldscript.sh
--- all3929-1/misc/mkldscript.sh Sun Dec 12 21:51:24 1999
+++ all3929-2/misc/mkldscript.sh Tue Dec 14 02:10:01 1999
@@ -6,40 +6,6 @@
#! /bin/sh
# Helper for compiling programs that use the Allegro library.
-if [ "\$1" = "debug" ]; then
- lib=alld;
-elif [ "\$1" = "profile" ]; then
- lib=allp;
-elif [ "\$1" = "release" ]; then
- lib=alleg;
-else
- cat >&2 << EOF
-
-allegro-lib: generates linker commands for the Allegro library.
-
-Usage:
-
- allegro-lib release [shared]
- allegro-lib debug [shared]
- allegro-lib profile [shared]
-
-In all cases the 'shared' parameter is optional, and should be included
-precisely when you're expecting to link with a shared library.
-
-For example:
-
- gcc myfile.o \\\`allegro-lib release\\\` -o myfile
-
-EOF
- exit
-fi
-
-if [ "\$2" = "shared" ]; then
- echo -n "-l\${lib} -l\${lib}_nonshared ";
-else
- echo -n "-l\${lib}_backend ";
-fi
-
echo "$*"
OUTER_EOF