balsa build help
Jules Bean
architecture!
In each case, the failure looks like this:
checking for ldap_search in -lldap... no
configure: error: *** You enabled LDAP but ldap library is not found.
make: *** [build-stamp] Error 1
******************************************************************************
...but this is weird. The configure test looks like this:
LIBS="-lldap -llber $LIBS"
cat > conftest.$ac_ext <<EOF
#line 8735 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char ldap_search();
int main() {
ldap_search()
; return 0; }
EOF
..so it should suffice to have properly working libldap.so and
liblber.so. On my machine, these are both provided by libldap2-dev.
But balsa *does* build depend on libldap2-dev! And the build logs
clearly show it being installed by sbuild.
I can't see what's happening (without looking inside the config.log
file, I guess).
Help?
Jules
PS. When I have buildd problems, is there a canonical place to
contact porters? I remember being told that debian-68k was the wrong
place for 68k; what about the other architectures?
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Domenico Andreoli
...
configure:8727: checking for ldap_search in -lldap
configure:8746: gcc -o conftest -g -O2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -D_REENTRANT -I/usr/include/gtk-1.2 -I/usr/include/
glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include conftest.c -lldap -llber -lpspell -L/usr/lib -lgthread -lglib -lpthread 1>&5
/usr/lib/libpspell.so: undefined reference to `ios virtual table'
/usr/lib/libpspell.so: undefined reference to `ostream::flush(void)'
/usr/lib/libpspell.so: undefined reference to `istream::ios virtual table'
/usr/lib/libpspell.so: undefined reference to `ostream::operator<<(char const *)'
/usr/lib/libpspell.so: undefined reference to `ostream & operator<<<int>(ostream &, smanip<int> const &)'
/usr/lib/libpspell.so: undefined reference to `ifstream::~ifstream(void)'
/usr/lib/libpspell.so: undefined reference to `__iomanip_setw(ios &, int)'
/usr/lib/libpspell.so: undefined reference to `fstreambase::fstreambase(int, char const *, int, int)'
/usr/lib/libpspell.so: undefined reference to `ifstream::ios virtual table'
collect2: ld returned 1 exit status
configure: failed program was:
#line 8735 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char ldap_search();
int main() {
ldap_search()
; return 0; }
[ EOF ]
as you see, this seems to be a problem of libpspell... i already
suspected of it, but i waited to see some other failure. sorry...
this problem is the same on suse 7.3, please see thread at
http://mail.gnome.org/archives/balsa-list/2001-December/msg00056.html.
since i didn't change almost anything in between 0.12.2-2 and -3,
if not a run of libtoolize or the like, i think it is a problem of
libtool buried somewhere.
it seems to be a missing "-lstdc++" somewhere...
is it possible?
hmm... so it would not really be a pspell failure...
any new hint?
making a search for "undefined reference to `ios virtual table'" with
google gives lots of matches...
regards
-----[ Domenico Andreoli, aka cavok
--[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Adam Majer
You can rename the file to .cpp or .cc or force C++ compilation for all
files.
- Adam
PS. lstrc++ is missed because c programs don't use that...
On Wed, Jan 23, 2002 at 05:12:42PM +0100, Domenico Andreoli wrote:
> [ from config.log ]
>
> ...
> configure:8727: checking for ldap_search in -lldap
> configure:8746: gcc -o conftest -g -O2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -D_REENTRANT -I/usr/include/gtk-1.2 -I/usr/include/
> glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include conftest.c -lldap -llber -lpspell -L/usr/lib -lgthread -lglib -lpthread 1>&5
> /usr/lib/libpspell.so: undefined reference to `ios virtual table'
> /usr/lib/libpspell.so: undefined reference to `ostream::flush(void)'
> /usr/lib/libpspell.so: undefined reference to `istream::ios virtual table'
> /usr/lib/libpspell.so: undefined reference to `ostream::operator<<(char const *)'
> /usr/lib/libpspell.so: undefined reference to `ostream & operator<<<int>(ostream &, smanip<int> const &)'
> /usr/lib/libpspell.so: undefined reference to `ifstream::~ifstream(void)'
> /usr/lib/libpspell.so: undefined reference to `__iomanip_setw(ios &, int)'
> /usr/lib/libpspell.so: undefined reference to `fstreambase::fstreambase(int, char const *, int, int)'
> /usr/lib/libpspell.so: undefined reference to `ifstream::ios virtual table'
> collect2: ld returned 1 exit status
> configure: failed program was:
> #line 8735 "configure"
> #include "confdefs.h"
> /* Override any gcc2 internal prototype to avoid an error. */
> /* We use char because int might match the return type of a gcc2
> builtin and then its argument prototype would still apply. */
> char ldap_search();
>
> int main() {
> ldap_search()
> ; return 0; }
>
> [ EOF ]
>
>
> as you see, this seems to be a problem of libpspell... i already
> suspected of it, but i waited to see some other failure. sorry...
>
> this problem is the same on suse 7.3, please see thread at
> http://mail.gnome.org/archives/balsa-list/2001-December/msg00056.html.
>
> since i didn't change almost anything in between 0.12.2-2 and -3,
> if not a run of libtoolize or the like, i think it is a problem of
> libtool buried somewhere.
>
> it seems to be a missing "-lstdc++" somewhere...
>
> is it possible?
>
> hmm... so it would not really be a pspell failure...
>
> any new hint?
>
> making a search for "undefined reference to `ios virtual table'" with
> google gives lots of matches...
>
> regards
5A
Yves Arrouye
> From: Adam Majer [mailto:ad...@galacticasoftware.com]
> Sent: Wednesday, January 23, 2002 1:47 PM
> To: Domenico Andreoli
> Cc: Jules Bean; debian...@lists.debian.org
> Subject: Re: balsa build help
>
> The problem is that this is a C++ file not a C file - the extention is
> screwed up...
> You can rename the file to .cpp or .cc or force C++ compilation for all
> files.
>
> - Adam
It is a C file. But one of the libraries it links against depends on the C++
runtime, which is usually added by the C++ driver.
Something like:
LIBS="$LIBS -lstdc++"
before the test should help. Or you could change the language to
(AC_SET_LANG) to C++ and then the test should be compiled as C++.
YA
Junichi Uekawa
> libpspell is a C++ library, and needs to be linked against libc++.
>
> 06:52pm gl...@zewt.pts/2 [~] ldd /usr/lib/libpspell.so
> libltdl.so.3 => /usr/lib/libltdl.so.3 (0x4002b000)
> libpspell-modules.so.1 => /usr/lib/libpspell-modules.so.1 (0x40031000)
> libc.so.6 => /lib/libc.so.6 (0x40033000)
> libdl.so.2 => /lib/libdl.so.2 (0x40157000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)
>
> This should list libstdc++; this is a bug. (Filed.)
This reminds me of bug #128391
Which essentially was that
$ libtool c++ [linking operation to make a .so]
invokes gcc, not g++, and I was pretty puzzled by the behavior.
regards,
junichi
--
dan...@debian.org : Junichi Uekawa http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Jules Bean
> 06:52pm gl...@zewt.pts/2 [~] ldd /usr/lib/libpspell.so
[snip]
> This should list libstdc++; this is a bug. (Filed.)
Thanks!
> Since this test doesn't seem to have anything to do with pspell, it
> doesn't need to link against it. If this doesn't get fixed soon in
> pspell, the best fix you could make is to not link this test against
> pspell. I'm not sure why autoconf does this. (I'd think this would
> cause problems; the test is merely to find if a library is available,
> and linking against other tested libraries could make it fail if they
> conflicted in some way.)
The problem will reoccur when the final executable is linked, though,
won't it? Since the final executable (balsa) is a C-executable.
There is logic in autoconf linking libraries incrementally
(i.e. linking all previously discovered libraries into each successive
test) - since the final executable will be linked with them all, why
not discover the incompatibilty at configure time?
Jules
Jules Bean
> Indeed. Looking at the pspell headers it seems libpspell is a mixed
> C/C++ library. That is bad practice anyway, but especially since
> it isn't linked against libstc++.
pspell is written in C++, but exports a C interface, I believe.
Is that bad practice?
Even if it is, we are stuck with it. Surely the author will not
rewrite it in pure C.
AIUI, the only reason that this is considered bad practice is the
instability (and non-uniformity) of the C++ ABI.
> I would suggest reporting a bug against libpspell, demanding a split
> in, say libpspell and libpspell++, or similiar.
Bug filed by Glenn (for which my thanks). But not for a split.
How could the split sensibly be performed, given that pspell is
written in C++?
Jules
Andreas Rottmann
> On Thu, Jan 24, 2002 at 11:32:34AM +0100, Andreas Rottmann wrote:
> > Indeed. Looking at the pspell headers it seems libpspell is a mixed
> > C/C++ library. That is bad practice anyway, but especially since
> > it isn't linked against libstc++.
>
> pspell is written in C++, but exports a C interface, I believe.
>
> Is that bad practice?
>
> Even if it is, we are stuck with it. Surely the author will not
> rewrite it in pure C.
>
> AIUI, the only reason that this is considered bad practice is the
> instability (and non-uniformity) of the C++ ABI.
>
> > I would suggest reporting a bug against libpspell, demanding a split
> > in, say libpspell and libpspell++, or similiar.
>
> Bug filed by Glenn (for which my thanks). But not for a split.
>
> How could the split sensibly be performed, given that pspell is
> written in C++?
>
If it's written in C++, it cannot be split. But anyhow, it must link
against libstdc++. I thought it might be consisting of a C part and a
C++ part (independent of each other).
Andy
--
Andreas Rottmann | Dru@ICQ | 118634484@ICQ | a.rot...@gmx.at
Georg-Rendlweg 28 | A-5111 Bürmoos | Austria | Europe
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Glenn Maynard
> > Indeed. Looking at the pspell headers it seems libpspell is a mixed
> > C/C++ library. That is bad practice anyway, but especially since
> > it isn't linked against libstc++.
>
> pspell is written in C++, but exports a C interface, I believe.
>
> Is that bad practice?
There's nothing wrong with that. It's *far* better than writing an
entire library in C.
> AIUI, the only reason that this is considered bad practice is the
> instability (and non-uniformity) of the C++ ABI.
I don't think that effects the portion of the API exported to C.
> > I would suggest reporting a bug against libpspell, demanding a split
> > in, say libpspell and libpspell++, or similiar.
That's completely unnecessary. (And, er, "demanding" it would be a
quick way to find myself ignored ...) It would certainly do nothing to
solve this problem.
> How could the split sensibly be performed, given that pspell is
> written in C++?
Often, libraries are written in C++, then a C wrapper is written around
them to give a C interface; but that wrapper itself has to be in C++, to
be able to use the C++ library. There's nothing wrong with that.
Other times, libraries will be written with a C API but in C++; I don't
believe this is the case with pspell. (I much prefer this to writing
completely in C; very often, the only reason people write libraries in C
is to "let people who only want to use C use the library", and that's
uninformed reasoning.)
--
Glenn Maynard
Gerhard Muntingh
> On Mon, Jan 28, 2002 at 04:32:06PM -0500, Glenn Maynard wrote:
> > installed. I see quite a number of them in /usr/lib. (Look at it; note
> > that it has information about how the library is going to be installed,
> > etc; it's not meant to be installed itself.)
[...]
> An ever increasing number of packages are using libtool to do their linking.
> The latest GNU libtools (>= 1.3a) can take advantage of the metadata in the
> installed libtool archive files (*.la files). The main advantage of
> libtool's .la files is that it allows libtool to store and subsequently
> access metadata with respect to the libraries it builds. libtool will search
> for those files, which contain a lot of useful information about a library
> (such as library dependency information for static linking). Also, they're
> essential for programs using libltdl.[38]
>
> Packages that use libtool to create shared libraries should include the .la
> files in the -dev package, unless the package relies on libtool's libltdl
> library, in which case the .la files must go in the run-time library
> package.
well I really don't like all the absolute paths in the .la files.
I think all installed files should be location independent.
RPM has locationindependant pkg's and Debian doesn't. I find this a
great disadvantage. It would make transitions (like /usr/doc ->
/usr/share/doc) and local mods much easier.
(btw: Ofcourse I agree with .la files being installed.)
regards,
Gerhard.
Gerhard Muntingh
> > all installed files should be location independent.
>
yes :( And I have more unattainable ideals :)
> Every deb is a "location independent" package:
>
> dpkg -i --instdir=/usr/local/somewhere
but you can't do: dpkg -i --relocate /usr/doc=/usr/share/doc
regards,
Gerhard.
Phil Edwards
Glenn Maynard <g_...@zewt.org>:
> I don't think most of the -L arguments need to be in dependency_libs
> anyway--not in the installed version, anyway. Most of them are either
> paths that are implicit anyway (-L/usr/lib) or ones that were only
> used during the build.
>
> Obscene path of the day:
>
> /usr/lib/libbfd.la:dependency_libs='
> -L/src/binutils/2.11.92.0.12.3-5/binutils-2.11.92.0.12.3/build-tree/binutils-2.11.92.0.12.3/builddir-single/libiberty/pic
> -liberty'
It's a known libtool bug. Currently there's no way to tell libtool which
-L options are "transient".
Phil
--
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace. We seek
not your counsel, nor your arms. Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen. - Samuel Adams
Adam Heath
> dpkg -i --exclude=/usr/share
>
> or something similar, which I think has some chance of being implemented one
> day to allow /usr/share to actually be shared.
I already implemented this, just never checked it in to cvs.
H. S. Teoh
> > > but you can't do: dpkg -i --relocate /usr/doc=/usr/share/doc
> >
> > though, it would not give you any real flexibility unless installed programs
> > were able to dynamically adapt to being relocated. So I don't think that it
> > would be worthwhile to implement at this time.
> >
> Is this really true? I thought any program is usually relocatable
> written. I myself have never written any location dependend.
[snip]
Most programs are relocatable, but only as far as compiling default paths
into the binary (e.g. path prefixes: /usr vs. /usr/local vs. /opt, and so
on). Plus, some programs are compiled against environments in known
locations (e.g. X11 libraries in /usr/X11R6/lib, or X11 binaries which are
needed, etc.). You can't easily relocate this without rebuilding the
program.
I don't think we want dpkg to re-build the package upon installation just
so it can be relocated :-)
Of course, it can be argued that such paths shouldn't be hard-compiled
into the program -- and I'd tend to agree with that -- unfortunately, this
convention is too widespread and likely isn't going to change anytime
soon.
T
--
"I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you
already said that." -- User-Friendly
Matt Zimmerman
> [relocation at compile-time, not build-time]
>
> I don't think we want dpkg to re-build the package upon installation just
> so it can be relocated :-)
>
> Of course, it can be argued that such paths shouldn't be hard-compiled
> into the program -- and I'd tend to agree with that -- unfortunately, this
> convention is too widespread and likely isn't going to change anytime
> soon.
When a program is run, it has only the data within the executable to start
with. This has to be enough for it to find everything that it needs.
Can you think of another way that it can work? Before you suggest "read a
configuration file", consider that a configuration file must be found before
it can be read. Please don't say "environment variables", as one variable
per installed program is not workable. Determining the installation prefix
dynamically from the path to the executable is evil, and breaks many useful
constructs. You could create a global "registry" mapping package name ->
installation prefix, but that makes it impossible to have more than one
version installed under different prefixes (which in my opinion would be
half the point of relocation). You could have each executable hard-code a
magic string which would be patched at installation time to the real
installation prefix, but this also breaks very useful functionality (like
being able to unpack a package by hand and use it).
--
- mdz
Gerhard Muntingh
(it's also fhs offtopic). But I would like to have this discussion.
> On Wed, Jan 30, 2002 at 03:05:28PM -0500, H. S. Teoh wrote:
> > Of course, it can be argued that such paths shouldn't be hard-compiled
> > into the program -- and I'd tend to agree with that -- unfortunately, this
> > convention is too widespread and likely isn't going to change anytime
> > soon.
You are right. And the benefits are minimal.
On Wed, Jan 30, 2002 at 04:41:01PM -0500, Matt Zimmerman wrote:
> Please don't say "environment variables", as one variable per installed
> program is not workable. Determining the installation prefix
> dynamically from the path to the executable is evil, and breaks many useful
> constructs.
"environment variables", sorry. How about dividing paths in 2 parts:
- System-dir (/, /usr, /var, /usr/local)
- Datatype-dir (/lib, /bin, /doc, /etc/foo-1.3-1/somedata.dat)
I think the Datatype should be hardcoded, and the System-dir could be
some sort of $PATH. I mailed idea also to the fhs mailinglist some time
ago($ALLPATH).
You can always override anything with environment variables or
commandline options, that would be a user customization.
Hurd would probably shadowfs the systemdirs. I don't really know
anything about bsd unionfs, but that would probably union them.
but,
What are the benefits?
----------------------
- It allows users to override any configuration, data, binaries in
a consistent way.
- Users can install anything anywhere they want, and it works.
- System-dirs are easily added and removed. (/usr/X11R6 -> /usr)
The not-benefits.
-----------------
- not feasible, too much has to change.
- I'll be flamed by people who have to change their cide or
people who don't find it beautiful at all.
- It'll likely break well established standards.
I'm not expecting anyone to change their code based on this.
Please comment, or suggest what the right place is to discuss.
Gerhard.
Bernhard R. Link
> What are the benefits?
> ----------------------
>
> - It allows users to override any configuration, data, binaries in
> a consistent way.
> - Users can install anything anywhere they want, and it works.
> - System-dirs are easily added and removed. (/usr/X11R6 -> /usr)
> Please comment, or suggest what the right place is to discuss.
And what are the benefits of the "benefits" given by you?
Sorry, I just see no reason at all why anything should be anywhere
else than /usr for packages /usr/local for
self-compiled-not-yet-packaged and /opt for crappy commercial
software.
Hochachtungsvoll,
Bernhard R. Link