[freetds] 0.61 tsql core dump, locale = "C C C C C C"

Cooperstock, Dan dan.cooperstock at hepcoe.com
Thu Jun 5 13:31:41 EDT 2003


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

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
I don't believe we ever figured out how to work around that.

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.

When I do the gdb thing you suggested on /usr/local/lib/libtds.sl.2.0, it
can't find the dumpfile symbol. (N.B. you gave the file name as .so, whereas
mine is .sl - is that relevant in any way?)

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

Dan Cooperstock, Senior Technical Consultant, HEPCOE Credit Union
dcoops at hepcoe.com    416-597-5055

-----Original Message-----
From: James K. Lowden [mailto:jklowden at schemamania.org]
Sent: Wednesday, June 04, 2003 8:47 PM
To: FreeTDS Development Group
Subject: Re: [freetds] 0.61 tsql core dump, locale = "C C C C C C"

On Wed, 4 Jun 2003 13:12:44 -0400 , "Cooperstock, Dan"
<dan.cooperstock at hepcoe.com> wrote:
> Is there something special I need to do to get the libraries to be
> compiled with symbol tables? I just did a basic compile with nothing
> very special when I created them. All I get from:
>       ldd $(which tsql) | grep libtds
> is:
>       libtds.sl.2 =>  /usr/local/lib/libtds.sl.2
> If I do:
>       file /usr/local/lib/libtds.sl.2
> I get:
>       /usr/local/lib/libtds.sl.2:     ELF-64 shared object file -
>       PA-RISC
> 2.0 (LP64)

Sanity check: You compiled with gcc, yes? 

On my machine, I have no CFLAGS in my normal environment, and the
top-level Makefile, generated with configure, sets "-g" (generate
symbols).  That's the default:

$ (cd build/; grep ^CFLAGS Makefile)
CFLAGS = -g -O2

(I don't run "./configure".  I have a ./build directory and "cd build;
../configure".)

If that doesn't work for you, see INSTALL for hints about setting your
environment before configure runs. 

I don't know if your file(1) would necessarily indicate whether symbols
are present in a shared library.  Another way to check is with gdb:

$ gdb /usr/local/lib/libtds.so.2.0
...
This GDB was configured as "i386--netbsdelf"...
.gdbinit:1: Error in sourced command file:
Function "main" not defined.
(gdb) p dumpfile
$1 = (FILE *) 0x0

--jkl

>
> Dan Cooperstock, Senior Technical Consultant, HEPCOE Credit Union
> dcoops at hepcoe.com    416-597-5055
>
> -----Original Message-----
> From: Lowden, James K [mailto:LowdenJK at bernstein.com]
> Sent: Wednesday, June 04, 2003 11:46 AM
> To: FreeTDS Development Group
> Subject: RE: [freetds] 0.61 tsql core dump, locale = "C C C C C C"
>
> > From: Cooperstock, Dan [mailto:dan.cooperstock at hepcoe.com]
> > Sent: June 4, 2003 10:20 AM
> >
> > OK, I'm back from 2 weeks' vacation.
>
> Oh, well.  ;-)
>
> > (gdb) watch dumpfile != 0
> > No symbol "dumpfile" in current context.
> >
> > What do I try next?
>
> Works for me?  The symbol is in libtds:
>
> $ grep -n dumpfile src/tds/util.c |head -1
> 69:static FILE *dumpfile = NULL;        /* file pointer for dump log */
>
> Maybe libtds wasn't compiled with "-g" or was stripped?
>
> $ ldd $(which tsql) |grep libtds |cut -f4 -d' ' \
>         |sed s'/$/*/'| sed 's/^/file /' |sh
> /usr/local/lib/libtds.so.2:   symbolic link to libtds.so.2.0
> /usr/local/lib/libtds.so.2.0: ELF 32-bit LSB shared object, Intel 80386,
> version 1, not stripped
>
> Or try "help symbol" in gdb.
>
> --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.
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds



More information about the FreeTDS mailing list