FreeTDS Development Group

["Craig A. Berry" <craigberry AT mac.com>]

At 2:08 PM -0500 12/13/03, James K. Lowden wrote:
>On 13 Dec 2003, Frediano Ziglio <freddyz77 AT tin.it> wrote:
>> Il sab, 2003-12-13 alle 09:38, James K. Lowden ha scritto:
>> >
>> > I don't anticipate linking in our iconv *and* a system iconv, so I
>> > don't see a reason to have two sets of names. 
>>
>> Assume your system have iconv in libc but you don't want to use this
>> version. You configure FreeTDS with --disable-libiconv. A program load
>> libc and FreeTDS. Now you have two iconv versions. Which iconv version
>> does another library loaded after FreeTDS one use?
>
>Assume your system has iconv in libc but you don't want to use this
>version. You configure FreeTDS with
>--with-libiconv-prefix=/usr/local/iconv.  Which iconv version
> does another library loaded after FreeTDS one use? 
>
>Answer:  The first one in the link list.  You can override anything in
>libc by inserting the object file (or archive) in the command line when
>linking the executable. 

So iconv.o and/or iconv.lo has to be installed with the FreeTDS
libraries and explicitly linked before any libraries that might also
include an iconv symbol?  Does this require any extra steps on the
part of the end user/programmer, or only on the part of the FreeTDS
maintainers?  BTW, the Tru64 linker manual says, "shared libraries
are searched before archive libraries" so I don't think the order you
are assuming is universal.

>Because libc is always linked in last, its
>objects are always precluded by higher-priority, same-name objects within
>the project. 

I can't find any explicit commitment to that in the GNU linker
manual, though this was my first look at that fine document and I
could well be missing something.  The Solaris linker manual does seem
to promise the behavior you are assuming.   The Tru64 linker manual
is a bit tentative; it says, "Ordering object files first *might*
prevent the inclusion of conflicting symbols that are also defined in
archive libraries or shared libraries specified on the ld command
line" (emphasis mine).  Note that it says "might", not "will" or "is
guaranteed to".  And one thing that became clear to me from reading
three linker manuals is that what's considered higher priority and
lower priority is implementation-defined; there are general trends
but no hard rules.

>AFAIK, all linkers work this way,

But is there any standard or technical necessity that requires them
to?  Assumptions about symbol resolution order strike me as
particularly vulnerable to optimization.  Consider something like
Apple's XCode, where compiling and linking is done incrementally (not
to mention distributed to multiple machines).  I don't know anything
about XCode's internals, but if I were trying to create an
intermediate link phase that wouldn't have to be redone when the
developer tweaked his or her project file, the first symbols I would
want to nail down and consider already resolved would be those
supplied by system libraries.

> else it's impossible to override the
>behavior of any function in any library. 

It's easy, just give it a different name.  Languages that support
overloading typically mangle the names in some automated fashion; the
safest procedure with C is to do the same thing manually.

>I understand that using different names prevents accidentally linking in
>the wrong iconv functions. 

Or generating linker warnings due to a multiply defined symbol.

>OTOH, any time we use preprocessor magic, we
>make understanding our work just that much harder.  I'm not sure what the
>best answer is. 

How hard is it to understand a one-line macro?   You wouldn't even
need to understand it unless you were reading config.h to find out
about the particulars of your environment.  We are not talking about
an #ifdef jungle sprouting up throughout the code, we are just
talking about a one-time preprocessor override for each function.

I hope this doesn't sound grumpy.  I've probably read the wrong
books, listened to the wrong records, and otherwise corrupted my
mind, but I honestly don't understand the preprocessor allergy that
keeps popping up here, especially in light of all the other risks
that are considered preferable.
-- 
________________________________________
Craig A. Berry
mailto:craigberry AT mac.com

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser