Re: [sqlite] Static sqlite3 library for Linux

[Petros Marinos]

Greetings Peter and thank you for your answer!

Ok, I’ll give these switches a go and will get back with my findings.

Concerning the side question, of course I can answer, no problem!
It is fully developed in-house.

Best Regards,
Petros

On 14 Feb 2018, 20:48 +0200, petern , wrote:
> Petros, FYI. gcc also has several different switches for object ouput:
> eg. "gcc -c -static ..."
>
> It might help to investigate these options during steps to compile sqlite.c
> and your main program to avoid dynamic/static symbol conflicts.
>
> -static
> On systems that support dynamic linking, this prevents linking
> with the shared libraries. On other systems, this option has no effect.
>
> -shared
> Produce a shared object which can then be linked with other
> objects to form an executable. Not all systems support this option. For
> predictable results,
> you must also specify the same set of options used for
> compilation (-fpic, -fPIC, or model suboptions) when you specify this
> linker option.[1]
>
> -shared-libgcc
> -static-libgcc
> On systems that provide libgcc as a shared library, these
> options force the use of either the shared or static version,
> respectively. If no shared version
> of libgcc was built when the compiler was configured, these
> options have no effect.
>
> There are several situations in which an application should use
> the shared libgcc instead of the static version. The most common of these
> is when the
> application wishes to throw and catch exceptions across
> different shared libraries. In that case, each of the libraries as well as
> the application itself
> should use the shared libgcc.
>
> Therefore, the G++ and GCJ drivers automatically add
> -shared-libgcc whenever you build a shared library or a main executable,
> because C++ and Java programs
> typically use exceptions, so this is the right thing to do.
>
> --
> I have a side question for you, if you can answer.
> How did Omilia implement their speaker independent speech recognition
> corpus? Was it licensed from elsewhere or developed in house?
>
> Peter
>
>
>
> On Wed, Feb 14, 2018 at 8:27 AM, Petros Marinos  wrote:
>
> > Thank you Arjen and Simon for your answers, really helpful!
> >
> > While there was progress by following the two commands noted in Arjen’s
> > answer and creating the libsqlite.a file, I stumbled upon the following
> > errors:
> >
> > [LD] astdb2sqlite3.o db1-ast/libdb1.a -> astdb2sqlite3
> > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> > In function `__libc_sigaction':
> > (.text+0x89f0): multiple definition of `__libc_sigaction'
> > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/
> > libc.a(sigaction.o):(.text+0x20): first defined here
> > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> > In function `__libc_fsync':
> > (.text+0x8100): multiple definition of `__libc_fsync'
> > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(fsync.o):(.text+0x0):
> > first defined here
> > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> > In function `__connect_nocancel':
> > (.text+0x7dc9): multiple definition of `__connect_nocancel'
> > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(connect.o):(.text+0x9):
> > first defined here
> > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> > In function `__libc_fcntl':
> > (.text+0x7c40): multiple definition of `__libc_fcntl'
> > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(fcntl.o):(.text+0xa0):
> > first defined here
> > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> > In function `__fsync_nocancel':
> > (.text+0x8109): multiple definition of `__fsync_nocancel'
> > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(fsync.o):(.text+0x9):
> > first defined here
> > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> > In function `_IO_funlockfile':
> > (.text+0x8990): multiple definition of `_IO_funlockfile'
> > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/
> > libc.a(funlockfile.o):(.text+0x0): first defined here
> > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> > In function `__libc_nanosleep':
> > (.text+0x8220): multiple definition of `__libc_nanosleep'
> > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/
> > libc.a(nanosleep.o):(.text+0x0): first defined here
> > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> > In function `__read':
> > (.text+0x7ae0): multiple definition of `__libc_read'
> > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(read.o):(.text+0x0):
> > first defined here
> > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> > In function 

Re: [sqlite] Static sqlite3 library for Linux

[petern]

Petros, FYI.  gcc also has several different switches for object ouput:
eg. "gcc -c -static  ..."

It might help to investigate these options during steps to compile sqlite.c
and your main program to avoid dynamic/static symbol conflicts.

   -static
   On systems that support dynamic linking, this prevents linking
with the shared libraries.  On other systems, this option has no effect.

   -shared
   Produce a shared object which can then be linked with other
objects to form an executable.  Not all systems support this option.  For
predictable results,
   you must also specify the same set of options used for
compilation (-fpic, -fPIC, or model suboptions) when you specify this
linker option.[1]

   -shared-libgcc
   -static-libgcc
   On systems that provide libgcc as a shared library, these
options force the use of either the shared or static version,
respectively.  If no shared version
   of libgcc was built when the compiler was configured, these
options have no effect.

   There are several situations in which an application should use
the shared libgcc instead of the static version.  The most common of these
is when the
   application wishes to throw and catch exceptions across
different shared libraries.  In that case, each of the libraries as well as
the application itself
   should use the shared libgcc.

   Therefore, the G++ and GCJ drivers automatically add
-shared-libgcc whenever you build a shared library or a main executable,
because C++ and Java programs
   typically use exceptions, so this is the right thing to do.

--
I have a side question for you, if you can answer.
How did Omilia implement their speaker independent speech recognition
corpus?  Was it licensed from elsewhere or developed in house?

Peter



On Wed, Feb 14, 2018 at 8:27 AM, Petros Marinos  wrote:

> Thank you Arjen and Simon for your answers, really helpful!
>
> While there was progress by following the two commands noted in Arjen’s
> answer and creating the libsqlite.a file, I stumbled upon the following
> errors:
>
> [LD] astdb2sqlite3.o db1-ast/libdb1.a -> astdb2sqlite3
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> In function `__libc_sigaction':
> (.text+0x89f0): multiple definition of `__libc_sigaction'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/
> libc.a(sigaction.o):(.text+0x20): first defined here
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> In function `__libc_fsync':
> (.text+0x8100): multiple definition of `__libc_fsync'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(fsync.o):(.text+0x0):
> first defined here
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> In function `__connect_nocancel':
> (.text+0x7dc9): multiple definition of `__connect_nocancel'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(connect.o):(.text+0x9):
> first defined here
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> In function `__libc_fcntl':
> (.text+0x7c40): multiple definition of `__libc_fcntl'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(fcntl.o):(.text+0xa0):
> first defined here
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> In function `__fsync_nocancel':
> (.text+0x8109): multiple definition of `__fsync_nocancel'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(fsync.o):(.text+0x9):
> first defined here
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> In function `_IO_funlockfile':
> (.text+0x8990): multiple definition of `_IO_funlockfile'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/
> libc.a(funlockfile.o):(.text+0x0): first defined here
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> In function `__libc_nanosleep':
> (.text+0x8220): multiple definition of `__libc_nanosleep'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/
> libc.a(nanosleep.o):(.text+0x0): first defined here
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> In function `__read':
> (.text+0x7ae0): multiple definition of `__libc_read'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(read.o):(.text+0x0):
> first defined here
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> In function `__open_nocancel':
> (.text+0x8289): multiple definition of `__open_nocancel'
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(open.o):(.text+0x9):
> first defined here
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
> In function `__lseek_nocancel':
> (.text+0x8169): multiple definition of 

Re: [sqlite] Static sqlite3 library for Linux

[Petros Marinos]

Thank you Arjen and Simon for your answers, really helpful!

While there was progress by following the two commands noted in Arjen’s answer 
and creating the libsqlite.a file, I stumbled upon the following errors:

[LD] astdb2sqlite3.o db1-ast/libdb1.a -> astdb2sqlite3
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
 In function `__libc_sigaction':
(.text+0x89f0): multiple definition of `__libc_sigaction'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(sigaction.o):(.text+0x20):
 first defined here
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
 In function `__libc_fsync':
(.text+0x8100): multiple definition of `__libc_fsync'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(fsync.o):(.text+0x0):
 first defined here
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
 In function `__connect_nocancel':
(.text+0x7dc9): multiple definition of `__connect_nocancel'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(connect.o):(.text+0x9):
 first defined here
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
 In function `__libc_fcntl':
(.text+0x7c40): multiple definition of `__libc_fcntl'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(fcntl.o):(.text+0xa0):
 first defined here
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
 In function `__fsync_nocancel':
(.text+0x8109): multiple definition of `__fsync_nocancel'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(fsync.o):(.text+0x9):
 first defined here
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
 In function `_IO_funlockfile':
(.text+0x8990): multiple definition of `_IO_funlockfile'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(funlockfile.o):(.text+0x0):
 first defined here
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
 In function `__libc_nanosleep':
(.text+0x8220): multiple definition of `__libc_nanosleep'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(nanosleep.o):(.text+0x0):
 first defined here
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
 In function `__read':
(.text+0x7ae0): multiple definition of `__libc_read'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(read.o):(.text+0x0):
 first defined here
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
 In function `__open_nocancel':
(.text+0x8289): multiple definition of `__open_nocancel'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(open.o):(.text+0x9):
 first defined here
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
 In function `__lseek_nocancel':
(.text+0x8169): multiple definition of `__lseek_nocancel'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(llseek.o):(.text+0x9):
 first defined here
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
 In function `__read_nocancel':
(.text+0x7ae9): multiple definition of `__read_nocancel'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(read.o):(.text+0x9):
 first defined here
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
 In function `send':
(.text+0x7f90): multiple definition of `__libc_send'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(send.o):(.text+0x0):
 first defined here
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
 In function `__libc_close':
(.text+0x7b40): multiple definition of `__libc_close'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(close.o):(.text+0x0):
 first defined here
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
 In function `__open':
(.text+0x8280): multiple definition of `__libc_open'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(open.o):(.text+0x0):
 first defined here
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
 In function `__write_nocancel':
(.text+0x7a89): multiple definition of `__write_nocancel'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(write.o):(.text+0x9):
 first defined here
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
 In function `__close_nocancel':
(.text+0x7b49): multiple definition of `__close_nocancel'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(close.o):(.text+0x9):
 first defined here
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libpthread.a(libpthread.o):
 In function `__fcntl_nocancel':
(.text+0x7ba0): multiple definition of `__fcntl_nocancel'
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libc.a(fcntl.o):(.text+0x0):
 first 

Re: [sqlite] Static sqlite3 library for Linux.

[Simon Slavin]

On 13 Feb 2018, at 10:55am, Petros Marinos  wrote:

> Is there any chance that I can find a Linux flavour static sqlite3 library, 
> or do I have to build from source?
> And if I have to build from source, is it recommended to use the 
> sqlite-autoconf or the sqlite-src pkg? Or does the amalgamation file could be 
> of any use, so as to avoid compilation etc?

It is recommended, in all possible cases, that you include the amalgamation 
source code (one .c file and one .h file) in your project.  Make sure your 
compiler understands that a .c file is C source code, not C++ source code.  The 
object code size of sqlite.c is very small and should not bulk up your program 
by much.

SQLite (talking about the API rather than the stand-alone tools) has no 
dependencies.  Therefore if you include the source code in your project rather 
than using SQLite as a library, you are adding no dependencies to your project. 
 This is important since a /lot/ of projects include SQLite and you can easily 
run into version disputes if you depend on a peculiarity of a certain version 
of SQLite.

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

Re: [sqlite] Static sqlite3 library for Linux

[Arjen Markus]

If you use the amalgamated source, there is only one file to be compiled. That 
can be as simple as:

gcc -c sqlite3.c

ar r libsqlite3.a sqlite3.o



Any further dependencies are up to the linker. No need to worry about that.



Regards,



Arjen


> -Original Message-
> From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
> Behalf
> Of Petros Marinos
> Sent: Wednesday, February 14, 2018 3:30 PM
> To: sqlite-users@mailinglists.sqlite.org
> Subject: [sqlite] Static sqlite3 library for Linux
>
> Greetings dears!
>
> While I am trying to build a static library of another tool which is 
> dependent to sqlite,
> I need to use an sqlite3 static library as well. Still, in my Centos 7.4 
> system, I
> cannot find one. The error is shown below:
>
> /bin/ld: cannot find -lsqlite3
> collect2: error: ld returned 1 exit status
> make[1]: *** [astdb2sqlite3] Error 1
> make: *** [utils] Error 2
>
> When I look for one with:
>
> yum provides */libsqlite*.a
>
> I find the Windows version:
>
> /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libsqlite3.a
>
> Which of course is useless:
>
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/.../.../.../.../lib64/libsqlite3.a: 
> error adding
> symbols: File format not recognized
> collect2: error: ld returned 1 exit status
> make[1]: *** [astdb2sqlite3] Error 1
> make: *** [utils] Error 2
>
> Is there any chance that I can find a Linux flavour static sqlite3 library, 
> or do I have
> to build from source?
>
> And if I have to build from source, is it recommended to use the 
> sqlite-autoconf or
> the sqlite-src pkg? Or does the amalgamation file could be of any use, so as 
> to
> avoid compilation etc?
>
> PS: One final relevant question, does the resulting libsqlite3.a file (when 
> built from
> source), includes any other libraries like libc.a, libthread.a etc? Is there 
> a way to
> avoid this?
>
> Thank you in advance for your time!
>
> Best Regards,
> Petros
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited. 
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users