[tlbuild] texlive-20120521 snapshot build failure on OpenBSD 5.1 i386

[Nelson H. F. Beebe]

I'm attempting to build the texlive-20120521 snapshot from earlier
today on OpenBSD 5.1 i386 without using any of the --without-xxx flags.

The attempt fails like this:

    /local/build/bare/texlive-20120521/source/Work/libs/icu/../../../libs/icu/icu-49.1/tools/makeconv/gencnvex.c:435:
    undefined reference to `u_strFromUTF32_49'
    gencnvex.o(.text.getToUnicodeValue+0x140):/local/build/bare/texlive-20120521/source/Work/libs/icu/../../../libs/icu/icu-49.1/tools/makeconv/gencnvex.c:456:
    undefined reference to `u_strFromUTF32_49'
    /usr/local/lib/libicuuc.so.4.0: undefined reference to `pthread_mutex_unlock'
    /usr/local/lib/libicuuc.so.4.0: undefined reference to `pthread_mutex_destroy'
    /usr/local/lib/libicuuc.so.4.0: undefined reference to `pthread_mutex_lock'
    /usr/local/lib/libicuuc.so.4.0: undefined reference to `pthread_mutex_init'
    collect2: ld returned 1 exit status

Those missing symbols are defined in -lpthread, so I restarted the
make like this:

    % cd source/Work
    % env GNUMAKE=/usr/local/bin/make \
	/usr/local/bin/make LIBS='/usr/local/lib/libfontconfig.a \
	    /usr/lib/libexpat.a /usr/local/lib/libfreetype.a /usr/local/lib/libbz2.a \
	    /usr/lib/libz.a -lpthread -lm' GNUMAKE=/usr/local/bin/make

It gets somewhat farther, than dies again with undefined references:

    /local/build/bare/texlive-20120521/source/Work/libs/icu/../../../libs/icu/icu-49.1/tools/makeconv/gencnvex.c:465: \
        undefined reference to `utm_countItems'
    gencnvex.o(.text.CnvExtWrite+0x19a):/local/build/bare/texlive-20120521/source/Work/libs/icu/../../../libs/icu/icu-49.1/tools/makeconv/gencnvex.c:371: undefined reference to `utm_alloc'
    gencnvex.o(.text.CnvExtWrite+0x1ad):/local/build/bare/texlive-20120521/source/Work/libs/icu/../../../libs/icu/icu-49.1/tools/makeconv/gencnvex.c:372: undefined reference to `utm_alloc'
    gencnvex.o(.text.CnvExtWrite+0x1ed):/local/build/bare/texlive-20120521/source/Work/libs/icu/../../../libs/icu/icu-49.1/tools/makeconv/gencnvex.c:377: undefined reference to `utm_countItems'
    gencnvex.o(.text.CnvExtWrite+0x20e):/local/build/bare/texlive-20120521/source/Work/libs/icu/../../../libs/icu/icu-49.1/tools/makeconv/gencnvex.c:693: undefined reference to `utm_alloc'

Further investigation shows that symbols like utm_alloc should be defined
in libicutu.a, and they are, sort of:

    % nm ./libs/icu/icu-build/lib/libicutu.a | grep utm_alloc
    00000000 ? utm_alloc
    00000000 ? utm_allocN

Notice that the symbols are prefixed with ? instead of the expect T;
the "man nm" command makes no mention of the ? symbol type flag.

Further experiments reveal the culprit:

    % g++ -c ~/c/hello.c 
    % nm hello.o
	     U __gxx_personality_v0
    00000000 F hello.c
    00000000 T main
	     U puts

    % g++ -c  -ffunction-sections -fdata-sections ~/c/hello.c
    % nm hello.o
	     U __gxx_personality_v0
    00000000 F hello.c
    00000000 ? main
	     U puts

The flags -ffunction-sections -fdata-sections are evidently the cause
of the ? flags.

Here is the documentation of those flags in the gcc info node
``Optimize Options'':

`-ffunction-sections'
`-fdata-sections'
     Place each function or data item into its own section in the output
     file if the target supports arbitrary sections.  The name of the
     function or the name of the data item determines the section's name
     in the output file.

     Use these options on systems where the linker can perform
     optimizations to improve locality of reference in the instruction
     space.  Most systems using the ELF object format and SPARC
     processors running Solaris 2 have linkers with such optimizations.
     AIX may have these optimizations in the future.

     Only use these options when there are significant benefits from
     doing so.  When you specify these options, the assembler and
     linker will create larger object and executable files and will
     also be slower.  You will not be able to use `gprof' on all
     systems if you specify this option and you may have problems with
     debugging if you specify both this option and `-g'.

It looks like they mainly affect optimization, so it should be
possible to remove them.

Before I attempt a rebuild with those flags removed, does anyone on
this list have prior experience with them, and is willing to make
recommendations?

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------