FreeTDS Development Group

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

> From: Cooperstock, Dan [mailto:dan.cooperstock AT hepcoe.com]
> Sent: June 5, 2003 1:32 PM

> I'm sure it's the same for you, but this is getting very frustrating.

I'm sure it's worse for you than for me.  I wish I knew more about your 
environment, because then I could guide you better.  

> Actually, I'm compiling with the HP-UX C compiler, cc. Is 
> that a problem?

I think so.  The gcc and gdb reference manuals talk about symbol formats.  I 
think atm your compiler is not emitting symbols that gdb understands, at 
least not in a shared library.  

> As you may recall, I can't configure the last nightly 
> snapshot I downloaded.
> Its output ends with:
>       
> finding the maximum length of command line arguments... 
> ./ltconfig[790]:
> There is not enough memory available now.
> configure: error: libtool configure failed

        :-(

This is coming from libtool, and I'm sorry to say I can't help you.  In the 
past, people with HP systems have had to patch the configure script.  IIRC, 
it had something to do with the shell's maximum command line size, but I 
really don't know.  For the record, and as you can see in the lt* files, we 
use libtool 1.4a.  

(You might also try the obvious: raising your process's memory limit with 
ulimit(1).)  

> In 0.61, there was no CFLAGS set in the master Makefile at all (in the
> freetds-0.61 directory). However, in the src subdirectory, I see:
>       CFLAGS = -g
> When I force it to recompile some stuff, it definitely uses -g.

"-g" is the gcc convention.  Your compiler may use different switches.  

> When I do the gdb thing you suggested on 
> /usr/local/lib/libtds.sl.2.0, it
> can't find the dumpfile symbol. 

Right.  That's consistent with the symbol format isssue: your compiler and 
debugger have to agree on the format of the debugging symbols if they're to 
be any use.  You could change your compiler, your debugger, or convince the 
compiler to emit the debugger's favorite symbol flavor, or maybe even 
convince gdb to read your compiler's output (once you know what that is).  

I realize we're debugging the debugger debugger debugger, far from what we're 
after.  Loading up the debugger to find out where the dumpfile handle is 
being overwritten is a brute force tactic.  A more entertaining technique 
might be to sprinkle printf() throughout the code to try to narrow down where 
it goes wrong, looking for bad 64-bit assumptions or casts.  

> (N.B. you gave the file name as .so, whereas
> mine is .sl - is that relevant in any way?)

You OS (or compiler?) apparently uses a different naming convention from 
mine.  I wonder if gcc on your OS creates .so ("shared object") or .sl 
("shared library"?) files.  

HTH.

--jkl
-----------------------------------------
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.