FreeTDS Development Group

[freddyz77 AT tin.it]

>
>>> I know there's one report in the recent archives of success
>>> building 0.62.3 on OS X, so there may be subtleties involved.
>>>  I'm happy to make any needed changes to the distribution,
>> Strike that: I meant to say "there's one report in the recent archives
>
>> of success building 0.62.4 and/or current CVS on OS X, no patches
>> required".
>
>It may have been me, as I do remember trying the first libtool-updated

>versions and having success with all except the odbc driver.
>
>The current nightly does not build easily any more, although it only
>fails near the end:
>
>gcc -dynamiclib -flat_namespace -undefined suppress -o
>.libs/libtds.3.0.dylib  -all_load  ./.libs/libtds_objects.a
>../replacements/.libs/libreplacements.a /usr/lib/libgcc.a
>/usr/lib/libiconv.dylib -install_name  /usr/local/lib/libtds.3.dylib
>-compatibility_version 4 -current_version 4.0
>ld: multiple definitions of symbol ___muldi3
>/usr/lib/libgcc.a(_muldi3.o) private external definition of ___muldi3
>in section (__TEXT,__text)
>/usr/lib/gcc/darwin/3.3/libgcc.a(_muldi3.o) private external definition

>of ___muldi3 in section (__TEXT,__text)
>[...]
>
>and this repeated for hundreds of definitions.
>
>I believe it's something to do with Freddy's recent change of
>
>> - include libgcc.a in shared libraries if someone try to compile with
>> gcc but do not use GNU ld. This should fix Solaris problem. It works
>> well using HP/UX 11.00.
>
>Here's one request to undo this change for Mac OS X (darwin). :)
>

I know.. I have just to commit change... I found that it's better to use
-static-libgcc libtool option instead of trying to link libgcc.a directly...
Also in some architectures I misdetect -Bsymbolic option (I have a patch
also for this...)

freddy77