Skip to Content.
Sympa Menu

freetds - Re: Release 0.41 ...on Solaris(Sparc)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: tetherow AT nol.org
  • To: freetds AT franklin.oit.unc.edu
  • Cc: greggj AT savvis.net
  • Subject: Re: Release 0.41 ...on Solaris(Sparc)
  • Date: Tue, 26 Jan 1999 16:42:47 -0600 (EST)


On 26 Jan, Gregg Jensen wrote:
> Brian Bruns wrote:
>
>> 0.41 is at ftp://sunsite.unc.edu/pub/Linux/ALPHA/freetds-0.41.tgz
>>
>> If I don't hear any complaints I'll send out the announcements tommorow
>> evening. I think Solaris is as good as it's going to be before the
>> release (I think I have some place to test Solaris if I keep quiet about
>> it, so I may look into the problems after the release).
>
> FYI,
> On Solaris (Sparc) with this tgz file, after running
>
> configure --prefix /opt/freetds --with-tdsver=4.2
>
> I get this output right off the bat with 'make':
>
> Making all in src
> make[1]: Entering directory `/devel/gwj/freetds/src'
> Making all in tds
> make[2]: Entering directory `/devel/gwj/freetds/src/tds'
> make[2]: *** No rule to make target `/usr/include/features.h', needed by
> `mem.lo'.
> Stop.
> make[2]: Leaving directory `/devel/gwj/freetds/src/tds'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/devel/gwj/freetds/src'
> make: *** [all-recursive] Error 1
>

When you untar the package, does it include a .deps directory anywhere?
If it does you need to remove it. As for the endian-ness we haven't
checked it since the last round that kevin replied to but it was
working then.

> Also, with the latest from CVS on Solaris, the make process completed but
> the flag
> for HW_BIG_ENDIAN/HW_LITTLE_ENDIAN was set to HW_LITTLE_ENDIAN.
> Interestingly
> enough, the other flag WORDS_BIGENDIAN was set to 1 (is this used in the
> code?).
> So, yes the build went ahead without errors, but I sure wouldn't want to
> try it out
> on Sybase. I have been told, (ahem...by the database administrator) that
> it causes
> a stack trace to occur and can bring down (or as a result, needs to bring
> down) the
> database.

I can't image how you could bring down a database with the wrong
endian-ness (not saying it is the case, but that it just baffles me
that someone could write a DB server that allows that kind of
misbehaviour :) It still bothers me that sybase/MS didn't use network
byte order for sending stuff across the network anyway.

------------------------------------------------------------------------
Sam Tetherow tetherow AT nol.org
Director of Development
Nebrask@ Online http://www.nol.org/





Archive powered by MHonArc 2.6.24.

Top of Page