master build issue

master build issue

[Neil Jerram]

I built and installed libunistring this evening, to /usr/local, and
now ./configure is failing for me at:

checking size of float... configure: error: cannot compute sizeof (float)

which is because (from config.log):

configure:52553: ccache gcc -o conftest -g -O2   conftest.c -L/usr/local/lib -lunistring -R/usr/local/lib -lgmp -lcrypt -lm -lltdl  >&5
gcc: unrecognized option '-R/usr/local/lib'

My GCC is version 4.3.2, so pretty recent.

Ludo, Andy, I'm wondering why this isn't a problem for you too.  Is it
because you've installed libunistring in /usr, perhaps?

Regards,
        Neil

Re: master build issue

[Andy Wingo]

On Thu 04 Jun 2009 03:04, Neil Jerram <neil@ossau.uklinux.net> writes:

> I built and installed libunistring this evening, to /usr/local, and
> now ./configure is failing for me at:
>
> checking size of float... configure: error: cannot compute sizeof
> (float)

I had this at one point today, as well, when I had installed
libunistring into /opt/foo/ but had my libdir wrong (/opt/foo/lib vs
/opt/foo/lib64)...

Crazy to get an error about sizeof(float). I wish unistring added its
info to UNISTRING_CFLAGS/UNISTRING_LIBS like other libraries instead of
CFLAGS so it would affect checks like this.

While we're complaining about the build :-) It seems we require gperf
now. Is that correct? Can that build-dependency be removed somehow? It
seems to be a build-time dependency, though it could be only for
maintainers.

If in fact it is only for maintainers, perhaps we should keep the
generated whatevers in git. I just had to ask the build folks at work to
add unistring as a dep, and I'm a little concerned about asking for
gperf too :P

> configure:52553: ccache gcc -o conftest -g -O2   conftest.c -L/usr/local/lib -lunistring -R/usr/local/lib -lgmp -lcrypt -lm -lltdl  >&5
> gcc: unrecognized option '-R/usr/local/lib'

I think that's how my error panned out too, but for you it should work.
Maybe we should get Bruno involved, if Ludovic doesn't know anything...

> Ludo, Andy, I'm wondering why this isn't a problem for you too.  Is it
> because you've installed libunistring in /usr, perhaps?

On my laptop, yes, in anticipation of someone packaging it up. Grr
unpackaged dependencies!!

Andy
-- 
http://wingolog.org/

Re: master build issue

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> On Thu 04 Jun 2009 03:04, Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> I built and installed libunistring this evening, to /usr/local, and
>> now ./configure is failing for me at:
>>
>> checking size of float... configure: error: cannot compute sizeof
>> (float)
>
> I had this at one point today, as well, when I had installed
> libunistring into /opt/foo/ but had my libdir wrong (/opt/foo/lib vs
> /opt/foo/lib64)...

Thanks for the ideas, Andy.  I'm also wondering if libtool v1.5.26 is
a factor (as against v2.2) - so now trying out libtool 2.2 from Debian
testing.

> While we're complaining about the build :-) It seems we require gperf
> now. Is that correct?

That's news to me.  Where have you seen that?

Regards,
        Neil

Re: master build issue

[Neil Jerram]

Neil Jerram <neil@ossau.uklinux.net> writes:

> I'm also wondering if libtool v1.5.26 is a factor (as against v2.2)
> - so now trying out libtool 2.2 from Debian testing.

Yes, that seems to do the trick.  So we require libtool 2.2 now...  I
guess that's OK, given that it's in Debian testing.

(I'll make an appropriate update to HACKING.)

Regards,
        Neil

Re: master build issue

[Neil Jerram]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> While we're complaining about the build :-) It seems we require gperf
>> now. Is that correct?
>
> That's news to me.  Where have you seen that?

OK, I've seen it now too; used to generate iconv_open-*.h from
iconv_open-*.gperf.  Brought in implicitly by gnulib.

It feels like an acceptable dependency to me, though.  Also, although
we could try to move some of this kind of building (assuming it really
is platform-independent) from make-time to autogen-time, I think that
would require quite a bit of work.

Regards,
        Neil

Re: master build issue

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]


Neil Jerram <neil@ossau.uklinux.net> writes:

> configure:52553: ccache gcc -o conftest -g -O2   conftest.c -L/usr/local/lib -lunistring -R/usr/local/lib -lgmp -lcrypt -lm -lltdl  >&5
> gcc: unrecognized option '-R/usr/local/lib'
>
> My GCC is version 4.3.2, so pretty recent.
>
> Ludo, Andy, I'm wondering why this isn't a problem for you too.  Is it
> because you've installed libunistring in /usr, perhaps?

I haven't tried it either, but it would seem prudent to verify that the
new dependency builds w/o hassle on all the places guile builds now.

I downloaded it and built on NetBSD/i386 5.0 with
--prefix=/usr/y0/libunistring, and it seems to build fine with no
warnings that I noticed as it scrolled by.  Looking at the package, it
looks quite well baked.  Despite my initial negative reaction to new
dependencies, this package seems exceptionally well done for one that
has (to me) appeared suddenly.  I did get one failure in make check:

test-striconveh.c:389: assertion failed
Jun  4 20:16:24 foo /netbsd: pid 28621 (test-striconveh), uid 10853: exited on signal 6 (core dumped)
[1]   Abort trap (core dumped) EXEEXT="" LOCALE...
FAIL: test-striconveh

but the rest were ok.

I can add it to pkgsrc, and that should fix my master build.


[-- Attachment #2: Type: application/pgp-signature, Size: 193 bytes --]

Re: master build issue

[Mike Gran]

> I downloaded it and built on NetBSD/i386 5.0 with
> --prefix=/usr/y0/libunistring, and it seems to build fine with no
> warnings that I noticed as it scrolled by.  Looking at the package, it
> looks quite well baked.  Despite my initial negative reaction to new
> dependencies, this package seems exceptionally well done for one that
> has (to me) appeared suddenly.  I did get one failure in make check:
> 

It's isn't really a "new" new package.  It is a library made from a
collection of the string functions provided by Gnulib.

If packaging it ended up being a great difficulty, you could end up
getting the same functionality by putting the identical Gnulib functions
in the ./lib directory of the Guile tarball.

Re: master build issue

[Neil Jerram]

Greg Troxel <gdt@ir.bbn.com> writes:

> looks quite well baked.  Despite my initial negative reaction to new
> dependencies, this package seems exceptionally well done for one that
> has (to me) appeared suddenly.  I did get one failure in make check:
>
> test-striconveh.c:389: assertion failed
> Jun  4 20:16:24 foo /netbsd: pid 28621 (test-striconveh), uid 10853: exited on signal 6 (core dumped)
> [1]   Abort trap (core dumped) EXEEXT="" LOCALE...
> FAIL: test-striconveh

That's something to report upstream.  Would you mind doing that?

Regards,
        Neil

Re: master build issue

[Ludovic Courtès]

Hi Neil,

Neil Jerram <neil@ossau.uklinux.net> writes:

> I built and installed libunistring this evening, to /usr/local, and
> now ./configure is failing for me at:
>
> checking size of float... configure: error: cannot compute sizeof (float)

Isn't it simply that `libunistring.so' is not in $LD_LIBRARY_PATH?  What
does `config.log' say?

Thanks,
Ludo'.