Re: [sqlite] [Makefile:1256: tcltest] Segmentation fault (core dumped)

[Dan Kennedy]

On 20/11/62 11:47, Dennis Clarke wrote:



Still on Red Hat Enterprise Linux here and now using CFLAGS wherein
there is no "std" specified.



The crash below is in test code - it is almost certainly a problem with 
the test scripts. If you can you send me the "test-out.txt" created by 
the [make tcltest] command, we should be able to figure out what is 
going on.


Thanks,

Dan.





I feel as if I am going in circles here however the codebase seems to
compile fine however the testsuite blows up in marvelous ways :

.
.
.
Time: walshared.test 26 ms
# WARNING: This next test takes around 12 seconds
gmake: *** [Makefile:1256: tcltest] Segmentation fault (core dumped)
real 368.93
user 327.66
sys 27.30
boe13$ find . -type f | grep -i 'core'
./testdir/core.8032
boe13$ file ./testdir/core.8032
./testdir/core.8032: ELF 64-bit LSB core file x86-64, version 1 
(SYSV), SVR4-style, from './testfixture 
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.00', 
real uid: 16411, effective uid: 16411, real gid: 20002, effective gid: 
20002, execfn: './testfixture', platform: 'x86_64'

boe13$
boe13$ find . -type f -name testfixture -ls
342992 5300 -rwxr-xr-x   1 dclarke  devl  5426184 Nov 20 04:35 
./testfixture

boe13$
boe13$ gdb ./testfixture ./testdir/core.8032
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"

and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from 
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/testfixture...done.

[New LWP 8032]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./testfixture 
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.00'.

Program terminated with signal 11, Segmentation fault.
#0  0x0043c71b in tvfsFileControl (pFile=0x1509af0, op=20, 
pArg=0x7ffde61bc9f8)
    at 
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/test_vfs.c:549

549   if( p->pScript && (p->mask_FCNTL_MASK) ){
Missing separate debuginfos, use: debuginfo-install 
glibc-2.17-196.el7.x86_64 libgcc-4.8.5-16.el7.x86_64

(gdb) where
#0  0x0043c71b in tvfsFileControl (pFile=0x1509af0, op=20, 
pArg=0x7ffde61bc9f8)
    at 
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/test_vfs.c:549
#1  0x0046c4e9 in sqlite3OsFileControl (id=0x1509af0, op=20, 
pArg=0x7ffde61bc9f8) at sqlite3.c:22475
#2  0x0048a47e in databaseIsUnmoved (pPager=0x1509970) at 
sqlite3.c:54928
#3  0x0048a59c in sqlite3PagerClose (pPager=0x1509970, 
db=0x14fbb70) at sqlite3.c:54969
#4  0x0049bf12 in sqlite3BtreeClose (p=0x159ea10) at 
sqlite3.c:66134
#5  0x0054ebac in sqlite3LeaveMutexAndCloseZombie 
(db=0x14fbb70) at sqlite3.c:157429
#6  0x0054eacc in sqlite3Close (db=0x14fbb70, forceZombie=0) 
at sqlite3.c:157372
#7  0x0054eaf0 in sqlite3_close (db=0x14fbb70) at 
sqlite3.c:157385

#8  0x004611cf in DbDeleteCmd (db=0x15bbab8)
    at 
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/tclsqlite.c:528
#9  0x7f9d19e18330 in Tcl_DeleteCommandFromToken 
(interp=0x1921c38, cmd=0x1350f48)

    at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:3184
#10 0x7f9d19e18179 in Tcl_DeleteCommand (interp=0x1921c38, 
cmdName=0x13acd98 "db")

    at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:3045
#11 0x00464d45 in DbObjCmd (cd=0x15bbab8, interp=0x1921c38, 
objc=2, objv=0x14ded88)
    at 
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/tclsqlite.c:2219
#12 0x7f9d19e19e2a in Dispatch (data=0x107d5e0, interp=0x1921c38, 
result=0)

    at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4418
#13 0x7f9d19e19eb7 in TclNRRunCallbacks (interp=0x1921c38, 
result=0, rootPtr=0x0)

    at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4451
#14 0x7f9d19e1c815 in TclEvalObjEx (interp=0x1921c38, 
objPtr=0x6161616161616161, flags=0, invoker=0xe87178, word=0)

    at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:6018
#15 0x7f9d19f24152 in SlaveEval (interp=0xe832f8, 
slaveInterp=0x1921c38, objc=1, objv=0xe871f0)

    at /opt/bw/build/nist/tcl8.7a1/generic/tclInterp.c:2826
#16 0x7f9d19f20bac in NRInterpCmd (clientData=0x0, 
interp=0xe832f8, objc=4, objv=0xe871d8)

    at /opt/bw/build/nist/tcl8.7a1/generic/tclInterp.c:885
#17 0x7f9d19e19e2a in Dispatch (data=0x17f8bb0, interp=0xe832f8, 
result=0)

    at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4418
#18 0x7f9d19e19eb7 in TclNRRunCallbacks (interp=0xe832f8, 
result=0, 

[sqlite] [Makefile:1256: tcltest] Segmentation fault (core dumped)

[Dennis Clarke]

Still on Red Hat Enterprise Linux here and now using CFLAGS wherein
there is no "std" specified.

I feel as if I am going in circles here however the codebase seems to
compile fine however the testsuite blows up in marvelous ways :

.
.
.
Time: walshared.test 26 ms
# WARNING: This next test takes around 12 seconds
gmake: *** [Makefile:1256: tcltest] Segmentation fault (core dumped)
real 368.93
user 327.66
sys 27.30
boe13$ find . -type f | grep -i 'core'
./testdir/core.8032
boe13$ file ./testdir/core.8032
./testdir/core.8032: ELF 64-bit LSB core file x86-64, version 1 (SYSV), 
SVR4-style, from './testfixture 
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.00', real 
uid: 16411, effective uid: 16411, real gid: 20002, effective gid: 20002, 
execfn: './testfixture', platform: 'x86_64'

boe13$
boe13$ find . -type f -name testfixture -ls
342992 5300 -rwxr-xr-x   1 dclarke  devl  5426184 Nov 20 04:35 
./testfixture

boe13$
boe13$ gdb ./testfixture ./testdir/core.8032
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from 
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/testfixture...done.

[New LWP 8032]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./testfixture 
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.00'.

Program terminated with signal 11, Segmentation fault.
#0  0x0043c71b in tvfsFileControl (pFile=0x1509af0, op=20, 
pArg=0x7ffde61bc9f8)
at 
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/test_vfs.c:549

549   if( p->pScript && (p->mask_FCNTL_MASK) ){
Missing separate debuginfos, use: debuginfo-install 
glibc-2.17-196.el7.x86_64 libgcc-4.8.5-16.el7.x86_64

(gdb) where
#0  0x0043c71b in tvfsFileControl (pFile=0x1509af0, op=20, 
pArg=0x7ffde61bc9f8)
at 
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/test_vfs.c:549
#1  0x0046c4e9 in sqlite3OsFileControl (id=0x1509af0, op=20, 
pArg=0x7ffde61bc9f8) at sqlite3.c:22475
#2  0x0048a47e in databaseIsUnmoved (pPager=0x1509970) at 
sqlite3.c:54928
#3  0x0048a59c in sqlite3PagerClose (pPager=0x1509970, 
db=0x14fbb70) at sqlite3.c:54969

#4  0x0049bf12 in sqlite3BtreeClose (p=0x159ea10) at sqlite3.c:66134
#5  0x0054ebac in sqlite3LeaveMutexAndCloseZombie (db=0x14fbb70) 
at sqlite3.c:157429
#6  0x0054eacc in sqlite3Close (db=0x14fbb70, forceZombie=0) at 
sqlite3.c:157372

#7  0x0054eaf0 in sqlite3_close (db=0x14fbb70) at sqlite3.c:157385
#8  0x004611cf in DbDeleteCmd (db=0x15bbab8)
at 
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/tclsqlite.c:528
#9  0x7f9d19e18330 in Tcl_DeleteCommandFromToken (interp=0x1921c38, 
cmd=0x1350f48)

at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:3184
#10 0x7f9d19e18179 in Tcl_DeleteCommand (interp=0x1921c38, 
cmdName=0x13acd98 "db")

at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:3045
#11 0x00464d45 in DbObjCmd (cd=0x15bbab8, interp=0x1921c38, 
objc=2, objv=0x14ded88)
at 
/opt/bw/build/sqlite-src-3300100_rhel_74_3.10.0-693.el7.x86_64.006/src/tclsqlite.c:2219
#12 0x7f9d19e19e2a in Dispatch (data=0x107d5e0, interp=0x1921c38, 
result=0)

at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4418
#13 0x7f9d19e19eb7 in TclNRRunCallbacks (interp=0x1921c38, result=0, 
rootPtr=0x0)

at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4451
#14 0x7f9d19e1c815 in TclEvalObjEx (interp=0x1921c38, 
objPtr=0x6161616161616161, flags=0, invoker=0xe87178, word=0)

at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:6018
#15 0x7f9d19f24152 in SlaveEval (interp=0xe832f8, 
slaveInterp=0x1921c38, objc=1, objv=0xe871f0)

at /opt/bw/build/nist/tcl8.7a1/generic/tclInterp.c:2826
#16 0x7f9d19f20bac in NRInterpCmd (clientData=0x0, interp=0xe832f8, 
objc=4, objv=0xe871d8)

at /opt/bw/build/nist/tcl8.7a1/generic/tclInterp.c:885
#17 0x7f9d19e19e2a in Dispatch (data=0x17f8bb0, interp=0xe832f8, 
result=0)

at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4418
#18 0x7f9d19e19eb7 in TclNRRunCallbacks (interp=0xe832f8, result=0, 
rootPtr=0x186aa38)

at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:4451
#19 0x7f9d19e1c815 in TclEvalObjEx (interp=0xe832f8, 
objPtr=0x6161616161616161, flags=0, invoker=0x0, word=0)

at /opt/bw/build/nist/tcl8.7a1/generic/tclBasic.c:6018
#20 0x7f9d19e1c7ae in Tcl_EvalObjEx 

Re: [sqlite] makefile for c

[Jan Hudec]

On Sun, Jan 15, 2012 at 15:17:37 -0600, Bill McCormick wrote:
> Tim Streater wrote, On 1/15/2012 3:00 PM:
> >On 15 Jan 2012 at 20:44, Bill McCormick  wrote:
> >
> >>What is the problem with the shared lib stuff?
> >>
> >>Black, Michael (IS) wrote, On 1/15/2012 2:27 PM:
> >>>A simple one -- and please compile sqlite3.c into your program and make
> >>>everybody happy.
> >>>
> >>>Forget the shared library stuff as we have just been talking about.
> >The problem is that the computer vendor installs a shared lib with
> >a version of the library. Some 3rd party app installer then replaced that
> >shared lib with another version, and existing apps don't like it.
> >
> >SQLite is small enough that it can be compiled and linked in in its entirety.

I am quite certain Debian requires packages to be linked dynamically to
libraries that are packaged, the strongest reason being security support.

Of course since Debian package declares dependency and versions, 3rd party
installer won't just replace the shared library with incompatible version.

> OK. I don't see this as a problem for my use case. It would be
> better for me to stick with the shared libs.
> 
> What is the difference between the two libs: libsqlite.so.0 and
> libsqlite3.so.0? I assume that I'll be linking to libsqlite3.

When you are compiling, you link against the .so file, which is symlink to
the actual .so.0 file. That file is provided by 'libsqlite3-dev' package and
is called '/usr/lib/libsqlite3.so'. The corresponding linker option is
'-lsqlite3'. Since the header is installed as '/usr/include/sqlite3.h', you
don't need any special options for compilation step. To see where the files
are, use 'dpkg -L libsqlite3-dev'.

-- 
 Jan 'Bulb' Hudec 
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] makefile for c

[Dan Kennedy]

On 01/16/2012 04:17 AM, Bill McCormick wrote:

Tim Streater wrote, On 1/15/2012 3:00 PM:

On 15 Jan 2012 at 20:44, Bill McCormick wrote:


What is the problem with the shared lib stuff?

Thanks!!
Black, Michael (IS) wrote, On 1/15/2012 2:27 PM:

A simple one -- and please compile sqlite3.c into your program and make
everybody happy.

Forget the shared library stuff as we have just been talking about.

The problem is that the computer vendor installs a shared lib with a
version of the library. Some 3rd party app installer then replaced
that shared lib with another version, and existing apps don't like it.

SQLite is small enough that it can be compiled and linked in in its
entirety.

--
Cheers -- Tim


OK. I don't see this as a problem for my use case. It would be better
for me to stick with the shared libs.

What is the difference between the two libs: libsqlite.so.0 and
libsqlite3.so.0?


"libsqlite.so.0" is probably sqlite version 2. It's around for
compatibility only, you don't want to use it for new programs.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] makefile for c

[Black, Michael (IS)]

If you insist on using the shared library instead of compiling in as we all 
recommend you don't need to worry about the different file extensions on the 
shared libraries.  There are no options when linking the shared libary.



CFLAGS=-O
OBJECTS=myapp.o
LIBS=-lsqlite3 -lpthread -ldl
myapp:  $(OBJECTS)
$(CC) -o $@ $(OBJECTS) $(LIBS)



Michael D. Black

Senior Scientist

Advanced Analytics Directorate

Advanced GEOINT Solutions Operating Unit

Northrop Grumman Information Systems


From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on 
behalf of Bill McCormick [wpmccorm...@gmail.com]
Sent: Sunday, January 15, 2012 3:17 PM
To: General Discussion of SQLite Database
Subject: EXT :Re: [sqlite] makefile for c

Tim Streater wrote, On 1/15/2012 3:00 PM:
> On 15 Jan 2012 at 20:44, Bill McCormick<wpmccorm...@gmail.com>  wrote:
>
>> What is the problem with the shared lib stuff?
>>
>> Thanks!!
>> Black, Michael (IS) wrote, On 1/15/2012 2:27 PM:
>>> A simple one -- and please compile sqlite3.c into your program and make
>>> everybody happy.
>>>
>>> Forget the shared library stuff as we have just been talking about.
> The problem is that the computer vendor installs a shared lib with a version 
> of the library. Some 3rd party app installer then replaced that shared lib 
> with another version, and existing apps don't like it.
>
> SQLite is small enough that it can be compiled and linked in in its entirety.
>
> --
> Cheers  --  Tim

OK. I don't see this as a problem for my use case. It would be better
for me to stick with the shared libs.

What is the difference between the two libs: libsqlite.so.0 and
libsqlite3.so.0? I assume that I'll be linking to libsqlite3.

What about options? Is there a makefile example out there somewhere?

Thanks!!
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] makefile for c

[Bill McCormick]

Tim Streater wrote, On 1/15/2012 3:00 PM:

On 15 Jan 2012 at 20:44, Bill McCormick  wrote:


What is the problem with the shared lib stuff?

Thanks!!
Black, Michael (IS) wrote, On 1/15/2012 2:27 PM:

A simple one -- and please compile sqlite3.c into your program and make
everybody happy.

Forget the shared library stuff as we have just been talking about.

The problem is that the computer vendor installs a shared lib with a version of 
the library. Some 3rd party app installer then replaced that shared lib with 
another version, and existing apps don't like it.

SQLite is small enough that it can be compiled and linked in in its entirety.

--
Cheers  --  Tim


OK. I don't see this as a problem for my use case. It would be better 
for me to stick with the shared libs.


What is the difference between the two libs: libsqlite.so.0 and 
libsqlite3.so.0? I assume that I'll be linking to libsqlite3.


What about options? Is there a makefile example out there somewhere?

Thanks!!
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] makefile for c

[Tim Streater]

On 15 Jan 2012 at 20:44, Bill McCormick  wrote: 

> What is the problem with the shared lib stuff?
>
> Thanks!!
> Black, Michael (IS) wrote, On 1/15/2012 2:27 PM:
>> A simple one -- and please compile sqlite3.c into your program and make
>> everybody happy.
>>
>> Forget the shared library stuff as we have just been talking about.

The problem is that the computer vendor installs a shared lib with a version of 
the library. Some 3rd party app installer then replaced that shared lib with 
another version, and existing apps don't like it.

SQLite is small enough that it can be compiled and linked in in its entirety.

--
Cheers  --  Tim
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] makefile for c

[Bill McCormick]

Sorry, I just joined the list so I'm not privy to anything "we have just 
been talking about".


I quick peek at the archives didn't reveal anything either.

Also, as I installed sqlite on Debian Squeeze with apt-get install (as 
opposed to compiling from source), I wouldn't have sqlite3.c to make 
sqlite3.o.


What is the problem with the shared lib stuff?

Thanks!!
Black, Michael (IS) wrote, On 1/15/2012 2:27 PM:

A simple one -- and please compile sqlite3.c into your program and make 
everybody happy.

Forget the shared library stuff as we have just been talking about.



CFLAGS=-O

OBJECTS=myapp.o sqlite3.o

LIBS=-lpthread -ldl

myapp:  $(OBJECTS)

 $(CC) -o $@ $(OBJECTS) $(LIBS)



Michael D. Black

Senior Scientist

Advanced Analytics Directorate

Advanced GEOINT Solutions Operating Unit

Northrop Grumman Information Systems


From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on 
behalf of Bill McCormick [wpmccorm...@gmail.com]
Sent: Sunday, January 15, 2012 2:23 PM
To: sqlite-users@sqlite.org
Subject: EXT :[sqlite] makefile for c

I'm looking for an example c program makefile for compiling and linking
in the SQLite lib to gcc compiled programs.

I'm not sure which lib to include between libsqlite.so.0 and
libsqlite3.so.0 and what options I should pass to gcc.

Where is this documented?

Thanks!!
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] makefile for c

[Black, Michael (IS)]

A simple one -- and please compile sqlite3.c into your program and make 
everybody happy.

Forget the shared library stuff as we have just been talking about.



CFLAGS=-O

OBJECTS=myapp.o sqlite3.o

LIBS=-lpthread -ldl

myapp:  $(OBJECTS)

$(CC) -o $@ $(OBJECTS) $(LIBS)



Michael D. Black

Senior Scientist

Advanced Analytics Directorate

Advanced GEOINT Solutions Operating Unit

Northrop Grumman Information Systems


From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on 
behalf of Bill McCormick [wpmccorm...@gmail.com]
Sent: Sunday, January 15, 2012 2:23 PM
To: sqlite-users@sqlite.org
Subject: EXT :[sqlite] makefile for c

I'm looking for an example c program makefile for compiling and linking
in the SQLite lib to gcc compiled programs.

I'm not sure which lib to include between libsqlite.so.0 and
libsqlite3.so.0 and what options I should pass to gcc.

Where is this documented?

Thanks!!
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] makefile for c

[Bill McCormick]

I'm looking for an example c program makefile for compiling and linking 
in the SQLite lib to gcc compiled programs.


I'm not sure which lib to include between libsqlite.so.0 and 
libsqlite3.so.0 and what options I should pass to gcc.


Where is this documented?

Thanks!!
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Makefile

[John Stanton]

Just removing the -g will not get rid of all the debugging information 
so strip will still give you a smaller executbale file.


Danilo wrote:

...or you can find and delete " -g" from the Makefile!

John Stanton ha scritto:


You can run strip on the file.

Ken wrote:

Is there a way to disable the -g flag for the library?  
I've found that the version compiled without the -g flags is about 3

times smaller (right around the 500k mark) but the default compile is
about 1.7 meg!

Is there a way to tell the Make to build a 32bit version vs a 64 bit?
If not this would be really nice.

Can the Make that is provided build a  libsqlite3.a and libsqlite3.so
from the amalgamated sqlite3.c ???

Thanks
Ken




-
To unsubscribe, send email to [EMAIL PROTECTED]
-




-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Makefile

[Ken]

Thanks Tom,
 
 
 That was just what I was looking for
 
 Regards,
 Ken
 

Tomash Brechko <[EMAIL PROTECTED]> wrote: On Wed, May 02, 2007 at 11:43:04 
-0700, Ken wrote:
> Is there a way to disable the -g flag for the library? 

Assuming you are using configure,

  ./configure CFLAGS='-O2'

After that 'make' will use only -O2, without -g. 


> Is there a way to tell the Make to build a 32bit version vs a 64
> bit? If not this would be really nice.

You may pass arbitrary compilation options as shown above, or you may
override the compiler itself with

  ./configure CC=/path/to/gcc32bit


> Can the Make that is provided build a libsqlite3.a and libsqlite3.so
> from the amalgamated sqlite3.c ???

No.  But the following quick-n-dirty-cut-n-paste patch will
(hopefully) do the job :)


--- Makefile.in-orig 2007-05-02 19:12:21.0 +0400
+++ Makefile.in 2007-05-03 00:16:07.0 +0400
@@ -130,6 +130,9 @@ LIBOBJ = alter.lo analyze.lo attach.lo a
  vdbe.lo vdbeapi.lo vdbeaux.lo vdbefifo.lo vdbemem.lo \
  where.lo utf.lo legacy.lo vtab.lo
 
+LIBOBJ = sqlite3.lo
+
+
 # All of the source code files.
 #
 SRC = \
@@ -315,6 +318,9 @@ lemon$(BEXE): $(TOP)/tool/lemon.c $(TOP)
 
 # Rules to build individual files
 #
+sqlite3.lo: sqlite3.c
+ $(LTCOMPILE) -c sqlite3.c
+
 alter.lo: $(TOP)/src/alter.c $(HDR)
  $(LTCOMPILE) -c $(TOP)/src/alter.c
 



-- 
   Tomash Brechko

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Makefile

[Tomash Brechko]

On Wed, May 02, 2007 at 11:43:04 -0700, Ken wrote:
> Is there a way to disable the -g flag for the library? 

Assuming you are using configure,

  ./configure CFLAGS='-O2'

After that 'make' will use only -O2, without -g. 


> Is there a way to tell the Make to build a 32bit version vs a 64
> bit? If not this would be really nice.

You may pass arbitrary compilation options as shown above, or you may
override the compiler itself with

  ./configure CC=/path/to/gcc32bit


> Can the Make that is provided build a libsqlite3.a and libsqlite3.so
> from the amalgamated sqlite3.c ???

No.  But the following quick-n-dirty-cut-n-paste patch will
(hopefully) do the job :)


--- Makefile.in-orig2007-05-02 19:12:21.0 +0400
+++ Makefile.in 2007-05-03 00:16:07.0 +0400
@@ -130,6 +130,9 @@ LIBOBJ = alter.lo analyze.lo attach.lo a
  vdbe.lo vdbeapi.lo vdbeaux.lo vdbefifo.lo vdbemem.lo \
  where.lo utf.lo legacy.lo vtab.lo
 
+LIBOBJ = sqlite3.lo
+
+
 # All of the source code files.
 #
 SRC = \
@@ -315,6 +318,9 @@ lemon$(BEXE):   $(TOP)/tool/lemon.c $(TOP)
 
 # Rules to build individual files
 #
+sqlite3.lo:sqlite3.c
+   $(LTCOMPILE) -c sqlite3.c
+
 alter.lo:  $(TOP)/src/alter.c $(HDR)
$(LTCOMPILE) -c $(TOP)/src/alter.c
 



-- 
   Tomash Brechko

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Makefile

[Danilo]

...or you can find and delete " -g" from the Makefile!

John Stanton ha scritto:
> You can run strip on the file.
> 
> Ken wrote:
>> Is there a way to disable the -g flag for the library?  
>>  I've found that the version compiled without the -g flags is about 3
>> times smaller (right around the 500k mark) but the default compile is
>> about 1.7 meg!
>>  
>>  Is there a way to tell the Make to build a 32bit version vs a 64 bit?
>> If not this would be really nice.
>>  
>>  Can the Make that is provided build a  libsqlite3.a and libsqlite3.so
>> from the amalgamated sqlite3.c ???
>>  
>>  Thanks
>>  Ken
>>  

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Makefile

[John Stanton]

You can run strip on the file.

Ken wrote:
Is there a way to disable the -g flag for the library? 
 
 I've found that the version compiled without the -g flags is about 3 times smaller (right around the 500k mark) but the default compile is about 1.7 meg!
 
 Is there a way to tell the Make to build a 32bit version vs a 64 bit? If not this would be really nice.
 
 Can the Make that is provided build a  libsqlite3.a and libsqlite3.so from the amalgamated sqlite3.c ???
 
 Thanks

 Ken
 
 
 
 






-
To unsubscribe, send email to [EMAIL PROTECTED]
-

[sqlite] Makefile

[Ken]

Is there a way to disable the -g flag for the library? 
 
 I've found that the version compiled without the -g flags is about 3 times 
smaller (right around the 500k mark) but the default compile is about 1.7 meg!
 
 Is there a way to tell the Make to build a 32bit version vs a 64 bit? If not 
this would be really nice.
 
 Can the Make that is provided build a  libsqlite3.a and libsqlite3.so from the 
amalgamated sqlite3.c ???
 
 Thanks
 Ken