[elinks-users] elinks-0.9.2 build issues

Jonas Fonseca fonseca at diku.dk
Wed Oct 20 05:02:09 PDT 2004

Nelson H. F. Beebe <beebe at math.utah.edu> wrote Tue, Oct 19, 2004:
> Today, I made build attempts for elinks-0.9.2 on these 20 Unix
> platforms:
[removed platform list]

Wow this is very cool. :) 

> Most were successful, or with a few tweaks, could be made to work; in
> several cases, I tried two or three different compilers to get a
> successful build.  I can provide details of the failures on request,
> including complete detailed logs of the configuration and make runs,
> but for now, will just summarize general problems to this list:

I would appreciate to get the logs sent to my own email adress.

> * The top-level config.{sub,guess} files are out-of-date, and neither
>   OSF/1 4.0 nor 5.1 are recognized.  I replaced them with the latest
>   versions from
> 	http://savannah.gnu.org/cgi-bin/viewcvs/config/config/config.guess?rev=HEAD&content-type=text/plain %% 
> 	http://savannah.gnu.org/cgi-bin/viewcvs/config/config/config.sub?rev=HEAD&content-type=text/plain
>   These are dated 6-Sep-2004, and are newer than the 21-Jun-2004
>   versions at ftp://ftp.gnu.org/gnu/config/.  The configure run was
>   then successful.  The rest of the build failed on both systems

Ok. Will update these ASAP if nobody beats me to it.

> * On several systems, I had to configure with --disable-nls to avoid
>   link-time errors with -liconv; this is a common problem that I've
>   seen on many other packages.

AFAIK it has only been reported for Mac OS X. Could it be our iconv.m4
that is out of date? I tried to google for something never but it didn't
look like there was something newer out there.

> * The Solaris 8 and 9 compilations failed, but the 7 one succeeded, so
>   I've used that build for the installation on our 8 and 9 systems.
> * On some systems, -liconv ended in a src/Makefile dependency list,
>   resulting in a build failure like this:
> 	No rule to make target `-liconv', needed by `elinks'.  Stop.
>   On some, I was able to remove that name from the dependency list and
>   complete the build.

iconv.m4 puts -liconv in LIBICONV (but not LIBS) and gettext.m4 appends
LIBICONV INTLLIBS which is used in elinks_DEPENDENCIES. So basicly we
should never append LIBICONV to INTLLIBS but instead just added it to

> * On several systems, I get this error:
> 	gcc: unrecognized option `-rdynamic'

I have met this error myself and suspect that the following code
from configure.in is wrong

	dnl Check for -rdynamic
	AC_MSG_CHECKING([for -rdynamic])
	LDFLAGS="$LDFLAGS -rdynamic"
	AC_TRY_LINK([], [], have_rdynamic=yes, have_rdynamic=no)
	test "$have_rdynamic" = no && LDFLAGS="$LDFLAGS_X"

Maybe actually compiling/linking some code will fix it

	AC_TRY_LINK([int a = 5;], [if (a == 5) a = 7;], have_rdynamic=yes, have_rdynamic=no)

>   and possibly associated with it, on Solaris 9 on SPARC and x86:
> 	ld: elf error: file scripting/libscripting.a: elf_getarsym
> 	ld: elf error: file scripting/guile/libscriptingguile.a: elf_getarsym
> 	ld: elf error: file scripting/lua/libscriptinglua.a: elf_getarsym
> 	ld: elf error: file protocol/smb/libsmb.a: elf_getarsym
> 	ld: fatal: File processing errors. No output written to elinks

I suspect the problem is that all these files are ``empty'' / contains
no symbols because all code in the archives has been out #defined.
It is fixed in the 0.10 branch and putting some dummy code/variable
could fix it for the 0.9 branch.

> * On the AMD Opteron (AMD64) on our 1024-node Beowulf cluster, the
>   wrong X11 libraries are used: the build attempts to use the 32-bit
>   libraries in /usr/X11R6/lib, but on this system, 64-bit compilations
>   are the default, and the correct flag needed is -L/usr/X11R6/lib64.

I think this is a autotool bug. We just use the AC_PATH_X macro.
The configure scripts provides an alternative so ...

  --x-includes=DIR    X include files are in DIR
  --x-libraries=DIR   X library files are in DIR

Jonas Fonseca

More information about the elinks-users mailing list