[freetds] Re: 0.63 Release Candidate 10
monroej_freetds at actualtechnologies.com
Sat Feb 12 17:37:38 EST 2005
On Feb 12, 2005, at 11:01 AM, Frediano Ziglio wrote:
> Il giorno lun, 07-02-2005 alle 11:49 -0600, Jonathan Monroe ha scritto:
>> On Feb 7, 2005, at 11:01 AM, Frediano ZIGLIO wrote:
>>>> ODBC shared libraries gets the wrong name, *.so. Other shared
>>>> get the correct .dylib name.
>>> Before to say it's wrong it's best to try it... in 0.62 I changed
>>> .dylib to .so cause iODBC (bundled with Max OS X 10.2 if I remember)
>>> refuse to load dylib but loads .so (don't ask me why...)
>> The iODBC libraries shipped with Darwin / OS X will load either a
>> .dylib or a .so (bundle). The loader checks the library type and then
>> calls the correct loading routines. I mentioned in a previous post
>> that Apple recommends that dylibs be built using "two level
>> Since the same symbols (SQLAllocHandle, etc) appear in both the driver
>> manager and the driver, the two level name space option ensures that
>> the application keeps the symbols separate. There are situations
>> conflicts occur when the libraries are built with flat name spaces.
>> I'm not sure if that's the problem you ran into - I can run the unit
>> tests with the library built as either a dylib or a bundle.
> Let's remember a bit of story. Mac OS X had some problem with library
> for some months we tried to fix it (trying changing libtool script with
> patch or even libtool version). The main problem is that there were
> few tester... If we change a line and we have to wait for a week or two
> this means that changing a line ten times require 2 months...
> After some time someone reported problems with ODBC (driver not
> Someone else report a link to Apple pages that tell that iODBC
> implementation had problems... After some months we discovered that
> using bundle instead of .dylib fix the issue. So we add -module to
> Makefile.am and we had no more reports (happily). Some time ago we
> discovered also that instead of upgrading libtool we could change link
> script (and so we did... happily no reports).
I understand your frustration here. I myself was never able to get the
libraries to build on darwin until Mark Lilback posted his build
instructions. The standard *nix build tools have come a long way since
then in terms of darwin support. In 2005, it looks like most public
projects include correct support for darwin in their build scripts. It
was a very different situation in 2003.
> Your mail, if I remember
> correctly, was in 0.62 RC phase so instead of trying to improve linking
> we "ignore" (not correct term...) your mail. Now we are still in RC and
> still this issue raise in a very bad period.
I apologize for not being more persistent about getting the changes
implemented once 0.62 was released. I'm just one user and I didn't see
anyone else voice an opinion. Since I wasn't able to make the changes
myself, I just let it go. In hind sight, I should have forced the
> As you say current scripts
> work so for 0.63 they are fine.
> You spot however two problems:
> 1) two level namespaces
> 2) module format
If you're building a dylib, you should definitely build with two level
namespaces for darwin 5.0 or later (versions earlier than 5.0 must use
flat namespaces). However, I think the real question is which type
should be built - dylibs or bundles.
Dylibs seem to be the preferred library format for darwin in general.
There are cases when a bundle might be a better choice. I think a
truly darwin friendly environment would support building both, much in
the same way that both iODBC and unixODBC are supported.
> 1) Probably the solution is to check is Mac OS X (which version provide
> this option?)? and add -Wl,-twolevel_namespace to src/odbc/Makefile.am
darwin 5.0 or later: two level namespace
else: flat namespace
> 2) still problem is version. Which version support correctly
> loading .dylib??
I believe all versions of darwin support loading dylibs. However,
Apple only started including the iODBC driver manager libraries
starting in darwin 6.
> All code I sent was from libtool output so another problem is: how
> libtool behave using -Wl,-twolevel_namespace and not using -module
> Mac OS X ??
I don't understand libtool at all, so I don't really understand your
question. However, if you give me some things to test, I will try them
on various environments and report the results back to you.
More information about the FreeTDS