FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

1345 6th Avenue, 39th floor
(212) 823-2646


> -----Original Message-----
> From: Craig A. Berry [mailto:craigberry AT mac.com]
> Sent: December 15, 2003 2:28 AM
> To: FreeTDS Development Group
> Subject: Re: [freetds] replacement iconv
> 
> 
> 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
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
> 
> 
-----------------------------------------
The information contained in this transmission may contain privileged and 
confidential information and is intended only for the use of the person(s) 
named above. If you are not the intended recipient, or an employee or agent 
responsible for delivering this message to the intended recipient, any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact 
the sender immediately by reply e-mail and destroy all copies of the original 
message. Please note that we do not accept account orders and/or instructions 
by e-mail, and therefore will not be responsible for carrying out such orders 
and/or instructions.