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
