guile build failure - help !

guile build failure - help !

[Dave Nadler]

Hi All - I'm trying to build guile under cygwin (GCC 3.4.4);
as I need it for autoconf (for some gcc work).
configure runs AOK at least I don't see anything wrong.
make runs for eons and then dies with the error below.
Many thanks in advance for any and all suggestions,
Best Regards, Dave

gcc -g -O2 -Wall -Wmissing-prototypes -Werror .libs/guile.exeS.o -o 
guile.exe guile-guile.o -Wl,--export-dynamic  ./.libs/libguile.a -lgmp 
-lcrypt -lltdl
guile-guile.o: In function `main':
/cygdrive/d/home/drn/guile-1.8.5/libguile/guile.c:72: undefined reference 
to `_l
t__PROGRAM__LTX_preloaded_symbols'
collect2: ld returned 1 exit status
rm -f .libs/guile.exeS.o
make[3]: *** [guile.exe] Error 1
make[3]: Leaving directory `/cygdrive/d/home/drn/guile-1.8.5/libguile'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/cygdrive/d/home/drn/guile-1.8.5/libguile'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/cygdrive/d/home/drn/guile-1.8.5'
make: *** [all] Error 2

Dave Nadler, USA East Coast voice (978) 263-0097,  drn@nadler.com 

Re: guile build failure - help !

[Andy Wingo]

Hi Dave,

On Thu 20 Nov 2008 00:01, Dave Nadler <Dave.Nadler@nadler.com> writes:

> /cygdrive/d/home/drn/guile-1.8.5/libguile/guile.c:72: undefined
> reference to `_l
> t__PROGRAM__LTX_preloaded_symbols'

I think this is because we don't support libltdl version 2.2 yet,
unfortunately. Someone with access to that version of libtool needs to
make a patch :) Until then, if it's possible, downgrade to libtool
1.5.26 and try again.

Sorry for the irritation,

Andy
-- 
http://wingolog.org/

Re: guile build failure - help !

[Neil Jerram]

2008/11/20 Andy Wingo <wingo@pobox.com>:
> Hi Dave,
>
> On Thu 20 Nov 2008 00:01, Dave Nadler <Dave.Nadler@nadler.com> writes:
>
>> /cygdrive/d/home/drn/guile-1.8.5/libguile/guile.c:72: undefined
>> reference to `_l
>> t__PROGRAM__LTX_preloaded_symbols'
>
> I think this is because we don't support libltdl version 2.2 yet,
> unfortunately. Someone with access to that version of libtool needs to
> make a patch :) Until then, if it's possible, downgrade to libtool
> 1.5.26 and try again.
>
> Sorry for the irritation,

I couldn't resist looking into this a bit more.

Seems there is a dependency between ltdl.h, which (in version 1.5.26) includes:

#define LTDL_SET_PRELOADED_SYMBOLS() 		LT_STMT_START{	\
	extern const lt_dlsymlist lt_preloaded_symbols[];		\
	lt_dlpreload_default(lt_preloaded_symbols);			\
						}LT_STMT_END

and libtool.m4, which (also in version 1.5.26) autogenerates code that includes:

/* The mapping between symbol names and symbols. */
const struct {
  const char *name;
  lt_ptr_t address;
}
lt_preloaded_symbols[[]] =
{
  ...

I haven't yet worked how the code generated by libtool.m4 eventually
gets linked with guile.c, but I'm pretty sure that's what happens.

When we (i.e. Ludovic :-)) builds a new Guile release, we do it on a
machine with libtool 1.5.26.  As part of the autogen.sh step, the
libtool.m4 on that machine gets copied into aclocal.m4, and aclocal.m4
is included in the release tarball.  So then the tarball is
effectively hardcoded to generate lt_preloaded_symbols.

When Guile is built on a machine with libtool 2.2, the problem is an
extra line in the libtool 2.2 version of ltdl.h:

#define lt_preloaded_symbols    lt__PROGRAM__LTX_preloaded_symbols

This causes the code in guile.c to reference
lt__PROGRAM__LTX_preloaded_symbols, and the aclocal.m4-generated code
doesn't define that, so we have an undefined reference.

Unfortunately, I can't yet see that this explanation suggests any nice
solutions...

    Neil

Re: guile build failure - help !

[Ludovic Courtès]

Hello!

"Neil Jerram" <neiljerram@googlemail.com> writes:

> When Guile is built on a machine with libtool 2.2, the problem is an
> extra line in the libtool 2.2 version of ltdl.h:
>
> #define lt_preloaded_symbols    lt__PROGRAM__LTX_preloaded_symbols
>
> This causes the code in guile.c to reference
> lt__PROGRAM__LTX_preloaded_symbols, and the aclocal.m4-generated code
> doesn't define that, so we have an undefined reference.

Thanks for finding this out!

At any rate, I think we should switch to Libtool 2.2 now, even for
1.8.6, as I don't expect it to introduce any regressions and it would be
mostly invisible to end-user since ltdl itself is compatible.

I saw Mike Gran's patch on `guile-user', and it seems to be the Right
Thing.  I'll try all that out and report back.

Thanks,
Ludo'.

Re: guile build failure - help !

[Neil Jerram]

2008/11/24 Ludovic Courtès <ludo@gnu.org>:
> Hello!
>
> "Neil Jerram" <neiljerram@googlemail.com> writes:
>
>> When Guile is built on a machine with libtool 2.2, the problem is an
>> extra line in the libtool 2.2 version of ltdl.h:
>>
>> #define lt_preloaded_symbols    lt__PROGRAM__LTX_preloaded_symbols
>>
>> This causes the code in guile.c to reference
>> lt__PROGRAM__LTX_preloaded_symbols, and the aclocal.m4-generated code
>> doesn't define that, so we have an undefined reference.
>
> Thanks for finding this out!
>
> At any rate, I think we should switch to Libtool 2.2 now, even for
> 1.8.6, as I don't expect it to introduce any regressions and it would be
> mostly invisible to end-user since ltdl itself is compatible.

It will be great if it is compatible to build with 2.2, but I don't
see how that can be possible, given my analysis.

Surely - if we build the distro with 2.2, and then a user tries to
build with 1.5.26 - we will then get a definition of
lt__PROGRAM__LTX_preloaded_symbols in the autogenerated code
(guileS.o), and a reference from guile.c to lt_preloaded_symbols.  And
hence still an unresolved external?

> I saw Mike Gran's patch on `guile-user', and it seems to be the Right
> Thing.  I'll try all that out and report back.

OK, great.

    Neil

Re: guile build failure - help !

[Ludovic Courtès]

Hi!

"Neil Jerram" <neiljerram@googlemail.com> writes:

> Surely - if we build the distro with 2.2, and then a user tries to
> build with 1.5.26 - we will then get a definition of
> lt__PROGRAM__LTX_preloaded_symbols in the autogenerated code
> (guileS.o), and a reference from guile.c to lt_preloaded_symbols.  And
> hence still an unresolved external?

By "building", you mean re-running `libtoolize', e.g., via `autoreconf'.

If by "building" we just mean running "./configure && make install",
then it's really compatible (Libtool is just a script that's bundled
with the tarball).

Now, it looks like `configure.in' will need to be changed incompatibly,
which means that developers will all have to switch to 2.2.  It's
annoying, but probably a reasonable thing to ask.  What do you think?

Thanks,
Ludo'.

Re: guile build failure - help !

[Neil Jerram]

2008/11/24 Ludovic Courtès <ludo@gnu.org>:
> Hi!
>
> "Neil Jerram" <neiljerram@googlemail.com> writes:
>
>> Surely - if we build the distro with 2.2, and then a user tries to
>> build with 1.5.26 - we will then get a definition of
>> lt__PROGRAM__LTX_preloaded_symbols in the autogenerated code
>> (guileS.o), and a reference from guile.c to lt_preloaded_symbols.  And
>> hence still an unresolved external?
>
> By "building", you mean re-running `libtoolize', e.g., via `autoreconf'.

No.  I mean just ./configure && make && make install.

> If by "building" we just mean running "./configure && make install",
> then it's really compatible (Libtool is just a script that's bundled
> with the tarball).

But the problem (as I see it) is that the script can be incompatible
with the /usr/include/libltdl.h on the user's machine.

> Now, it looks like `configure.in' will need to be changed incompatibly,
> which means that developers will all have to switch to 2.2.  It's
> annoying, but probably a reasonable thing to ask.  What do you think?

I'm not against doing that now (and I think it was only me against
before).  But I don't feel confident yet that we've understood the
technical implications of switching.

Regards,
         Neil

Re: guile build failure - help !

[Ludovic Courtès]

Hello,

"Neil Jerram" <neiljerram@googlemail.com> writes:

> But the problem (as I see it) is that the script can be incompatible
> with the /usr/include/libltdl.h on the user's machine.

Ah, right, sorry.  I re-read your initial message and I understand now.

One question remains open: can a Libtool2-powered package be built with
libltdl from 1.5?  If the answer is "yes", then we are on the safe side,
otherwise we'll have to require users to upgrade to Libtool 2.

Thanks,
Ludo'.

Re: guile build failure - help !

[Ludovic Courtès]

Hi,

Dave Nadler <Dave.Nadler@nadler.com> writes:

> gcc -g -O2 -Wall -Wmissing-prototypes -Werror .libs/guile.exeS.o -o 
> guile.exe guile-guile.o -Wl,--export-dynamic  ./.libs/libguile.a -lgmp
> -lcrypt -lltdl
> guile-guile.o: In function `main':
> /cygdrive/d/home/drn/guile-1.8.5/libguile/guile.c:72: undefined
> reference to `_l
> t__PROGRAM__LTX_preloaded_symbols'

Which version of Libtool do you use?  We don't support 2.x yet, so you
should yet 1.5.x.

Hope this helps,
Ludo'.

Re: guile build failure - libtool 2.2 ??

[Dave Nadler]

Ooops - I have libtool 2.2.
I will try again with the older version if I must...
Thanks !
Best Regards, Dave

At 12:02 PM 11/20/2008, Ludovic Courtès wrote:
>Hi,
>
>Dave Nadler <Dave.Nadler@nadler.com> writes:
>
> > gcc -g -O2 -Wall -Wmissing-prototypes -Werror .libs/guile.exeS.o -o
> > guile.exe guile-guile.o -Wl,--export-dynamic  ./.libs/libguile.a -lgmp
> > -lcrypt -lltdl
> > guile-guile.o: In function `main':
> > /cygdrive/d/home/drn/guile-1.8.5/libguile/guile.c:72: undefined
> > reference to `_l
> > t__PROGRAM__LTX_preloaded_symbols'
>
>Which version of Libtool do you use?  We don't support 2.x yet, so you
>should yet 1.5.x.
>
>Hope this helps,
>Ludo'.

Dave Nadler, USA East Coast voice (978) 263-0097,  drn@nadler.com