Bugzilla Bug 80226

The announcement on the ELinks homepage, http://elinks.or.cz/:

  [2005-01-30] 0.10.2 has been released
    Here goes another another sync with the unstable
  development branch. It contains a few new features,
  improvements and some very important fixes. The critical
  form bug (602) which was introduced shortly before 0.10 was
  branch has been fixed and I now consider 0.10.2 very much
  to be a release worthy for inclusions in various
  distributions.

And a link to the full announcement in the Bug link.

I have tried compiling it, but it failed because I'm evil and
have -ffunction-sections and -fdata-sections in my flags :)
A filter for that would be in order I think.

Removing the flags let it compile and work as far as I have
tested -- not much!

I've just add an ebuild for the new version. I haven't included the CFLAGS
filters (yet?) as it compiled and worked for me when I added
'-ffunction-sections' and '-fdata-sections' to my CFLAGS. Are you sure these
two are causing the problems? What version of gcc are you using? Please paste
the actual error messages you're getting if you experience any problems with
the new ebuild.

Hmm, I might as well post it here.

Summary:

 * -fdata-sections is evil, -ffunction-sections is innocent.
 * It's related to extern variables.
 * I blame it on bad code :)

Hack log:

  Right, this is what I get when building (it's built a lot
and I think it's time for it to link everything together)
ELinks 0.10.1 (formatted a bit):

make[4]: Leaving directory `/tmp/portage/elinks-0.10.1/work/elinks-0.10.1/src/viewer'
make[3]: Leaving directory `/tmp/portage/elinks-0.10.1/work/elinks-0.10.1/src/viewer'
make[3]: Entering directory `/tmp/portage/elinks-0.10.1/work/elinks-0.10.1/src'
gcc
	-DHAVE_CONFIG_H -I.. -I../src
	-O3 -march=pentium2 -ffunction-sections -fdata-sections -fbranch-target-load-optimize -funit-at-a-time -ftracer -pipe
	-Wall -Iyes/include -fno-strict-aliasing
	-c main.c
gcc
	-DHAVE_CONFIG_H -I.. -I../src
	-O3 -march=pentium2 -ffunction-sections -fdata-sections -fbranch-target-load-optimize -funit-at-a-time -ftracer -pipe
	-Wall -Iyes/include -fno-strict-aliasing
	-c vernum.c
gcc
	-O3 -march=pentium2 -ffunction-sections -fdata-sections -fbranch-target-load-optimize -funit-at-a-time -ftracer -pipe
	-Wall -Iyes/include -fno-strict-aliasing -Wl,-O1 -rdynamic
	-o elinks
		main.o
		vernum.o
		../src/intl/gettext/libintl.a
		modules/libmodules.a
		cookies/libcookies.a
		viewer/text/libviewer_text.a
		viewer/dump/libviewer_dump.a
		cache/libcache.a
		document/libdocument.a
		intl/libintl.a
		sched/libsched.a
		lowlevel/liblowlevel.a
		terminal/libterminal.a
		osdep/libosdep.a
		protocol/libprotocol.a
		ssl/libssl.a
		bookmarks/libbookmarks.a
		formhist/libformhist.a
		globhist/libglobhist.a
		config/libconfig.a
		dialogs/libdialogs.a
		mime/libmime.a
		bfu/libbfu.a
		encoding/libencoding.a
		util/libutil.a
	-Lyes/lib
	-lssl
	-lcrypto
	-ldl
	-lgpm
	-lz
	-lbz2
	-lexpat
cookies/libcookies.a(dialogs.o)(.data.cookie_queries+0x0): multiple definition of `cookie_queries'
cookies/libcookies.a(cookies.o)(.bss.cookie_queries+0x0): first defined here
sched/libsched.a(action.o)(.bss.cookie_queries+0x0): multiple definition of `cookie_queries'
cookies/libcookies.a(cookies.o)(.bss.cookie_queries+0x0): first defined here
sched/libsched.a(download.o)(.text.continue_download+0x13f): In function `continue_download':
: warning: the use of `tempnam' is dangerous, better use `mkstemp'
collect2: ld returned 1 exit status

  I am using the latest unstable GCC:
	gcc (GCC) 3.4.3 20050110 (Gentoo Linux 3.4.3.20050110, ssp-3.4.3.20050110-0, pie-8.7.7)

  And ld, whatever package it belongs to:
	GNU ld version 2.15.92.0.2 20040927

My CFLAGS are:
	-O3                           // All the extra options over -O2 increase
    	                          // performance for me in my benchmarks.
	-march=pentium2               // Why not? It's a small improvement AFAIK.
	-ffunction-sections           // I'm pretty sure these improve perf a bit,
	-fdata-sections               // otherwise they sound good on the paper ;)
	-fbranch-target-load-optimize // A very small probably riskless improvement.
	-ftracer                      // Same here but a bit more.
	-funit-at-a-time              // Hmm... can't remember results.
	-pipe                         // Rumored to speed up compilations, haven't
	                              // benchmarked.

;)

	I also use -O1 in my LDFLAGS AFAIK, but that does not
affect this.

	I get the same (pretty much) for 6 ebuilds when I do an
emerg-e --world. kbd is one of them. I'll try to see if
this is caused by my CFLAGS, one of them might not work
that well together with --ffunction-sections and
--fdata-sections.

Results:
full flags:
	i686-pc-linux-gnu-gcc -s
		setfont.o findfile.o xmalloc.o getfd.o
		mapscrn.o loadunimap.o kdmapop.o kdfontop.o
		psffontop.o utf8.o
		-o setfont
	kdmapop.o(.bss.progname+0x0): multiple definition of `progname'
	setfont.o(.bss.progname+0x0): first defined here
	kdfontop.o(.bss.progname+0x0): multiple definition of `progname'
	setfont.o(.bss.progname+0x0): first defined here
	collect2: ld returned 1 exit status
when compiling/linking

just ffunc, fdata:
	exactly the same
Hm, no good, I expected that to work.

just ffunc (I'm pretty sure fdata is the culprit):
Yep, that worked.

A build with just -fdata-sections fails... this is the one :/ It's probably
GCC's fault. I'll try building with my new and shiny GCC-4 if it finishes any
time soon...

Another possible cause is bad coding, it only happens in some programs (in my
--system at least.).

Analyzing the source shows that progname is a char * declared in a header:
	char * progname;
Not a very good declaration, it's asking for multiple defs :/

In the files it complains about, progname is simply used.

In the ones it doesn't complain about and where it's used, psffontop.c for
example, there is a line:
	extern char * progname;

I assume adding that to all the files (or fixing a better global var) would
work.

I added that line to kdmapop.c, no errors. Removing it caused the errors again
(why in just that file?). setfont.c didn't help, neither did kdfontop.c...
this is odd.

However, this should mean that I could fix the issue in ELinks, right?

*hacks around*

No :/ *hacks around some more* Or? Yes, declaring cookie_queries extern in
src/cookies/dialogs.h made it compile!

Now I'm tired. Oh, GCC-4 is on the last stage!

And, yes, GCC 4.0.0 worked, this is a bug in the GCC build... 'sort of' bug
anyway.

It was fixed in the upstream CVS right now, it should've been indeed declared
extern in the .h file. Thanks, it will be fixed in the next release. (You can
apply own trivial patch to change its declaration to extern in the meantime.)