Daniel E. Macks <[EMAIL PROTECTED]> wrote Wed, Jun 28, 2006:
> Clayton Smith <[EMAIL PROTECTED]> said:
>
> It's pretty unusual to link all those .o into a giant .o instead of
> archiving them in a .a, and it also makes it harder to track down
> where symbols definitions actually are. So elinks-devels...why is that
> being done?
I will try to answer you ramblings. Before the new GNU make "based"
build system was introduced we used .a files. There was one problem with
this, namely that some of these .a file had inter-dependencies when the
final elinks binary was being linked together. So everytime you needed
to add a new .a file you needed to randomly try to insert it into the
list of .a file until you found a way that didn't conflict and errored
out with undefined symbols. This was solved with not using .a files.
Recursively linking things into a general $subdir/lib.o also makes it
easier to add new directories and implementing conditional directory
decending. Now for every directory in SUBDIRS you can just check for
$subdir/lib.o and link it in if it exists. Before you could end up with
.a files in every subdir and then you needed to specify that this
$subdir/$subsubdir/lib.a should be linked in.
If there is a portable way to link several .a files into a super .a
file then that could of course also be used. If I recall correctly,
I didn't (bother to ;) figure out how to do that.
> I'm having trouble finding clear documentation of the
> changes you've made from the official gettext distro.
Yes, we should probably have done that. One thing I know of (apart from
switching gettext to mostly use ELinks's memory management system and
coding style instead of that horrible GNU one ;) is that _() will take a
terminal struct as an arg. This stems from the fact that several
terminals can exist, each with a different locale. It's probably not so
common in practice and I don't know why we bother to support that, but
it obviously has to do with ELinks instances being able to connect to
each other and share cache info etc. to minimize memory usage.
> > Here is the command that runs that actually produces the error:
> >
> > [EMAIL PROTECTED]/docs/downloads/elinks-0.11.1/src$ gcc -g -O2 -Wall
> > -fno-strict-aliasing -Wno-pointer-sign -o elinks lib.o -lssl -lcrypto
> > -ldl -lz -lbz2 -liconv
> > /usr/bin/ld: warning multiple definitions of symbol _locale_charset
> > lib.o definition of _locale_charset in section (__TEXT,__text)
> > /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libiconv.dylib(localcharset.o)
> > definition of _locale_charset
>
> There's long been a symbol with the same name in gettext (libintl) and
> iconv (libiconv). It usually only triggers a warning on OS X because
> each symbol lives in its own lib's namespace. If both definitions of
> the symbol wind up in the common namespace, however, there is a
> (fatal) collision. There might be a flag to instruct the linker to use
> symbols in the specific .o before those in the -l libs?
>
> The brute-force solution would be to rename the offending symbol in
> the elinks gettext.
This would probably be the best way to finally put this warning to rest.
There was talk about adding support for linking in a local gettext
version but for the reason I've explained above regarding _() this will
probably never happen and messing with various variables should be safe.
--
Jonas Fonseca
___
elinks-users mailing list
elinks-users@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-users
