Thanks for the info. Do you mind if I copy some of this information back to
the go-sqlite3 issues?
On Tue, Oct 4, 2016 at 1:27 PM Richard Hipp wrote:
On 10/4/16, Judson Lester wrote:
>
> That said, it's harmless until the deprecation turns into a removal at the
> OS level, at which point ignori
On 10/4/16, Judson Lester wrote:
> Thanks for the info. Do you mind if I copy some of this information back to
> the go-sqlite3 issues?
I do not mind.
--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.or
On 10/4/16, Judson Lester wrote:
>
> That said, it's harmless until the deprecation turns into a removal at the
> OS level, at which point ignoring the error becomes a sudden
> incompatibility with SQLite bindings.
>
Engineers at Apple tell me that they are still using
OSAtomicCompareAndSwapPtrBa
I can't prevent it being output as a consumer of the Go library. I've
needed to invest effort into my build chain to filter the warning; so
there's been some amount of pointless labor as a consequence. It might be
possible for the go-sqlite3 author to update the build commands to suppress
it?
All
Thanks very much. The warning itself recommends
atomic_compare_exchange_strong(),
but I can't tell you much more than that.
Would you be so kind as to let me know when/if there's a SQLite ticket for
this so that I can link it back to the project I encountered this in? It'll
help in terms of that m
On 10/4/16, Judson Lester wrote:
>
> Would you be so kind as to let me know when/if there's a SQLite ticket for
> this so that I can link it back to the project I encountered this in?
It's a harmless warning. *Harmless*. Can you not simply ignore it?
--
D. Richard Hipp
d...@sqlite.org
___
On 10/1/16, David Goldwich wrote:
> On Sat, Oct 1, 2016 at 4:41 PM, Simon Slavin wrote:
>> According to a 2012 post from DRH, try this compilation option:
>>
>> -DSQLITE_WITHOUT_ZONEMALLOC
>
> Another, probably better way would be -DOSATOMIC_USE_INLINED=1. That
> will transparently substitute leg
I understand that this project doesn't produce go-sqlite3, but the
sqlite-bindings.c that project incorporates (and which is the origin of the
deprecation warning) do seem to be part of this project. If that's not so,
can you direct me to the true source so I can raise the issue there?
On Sat, Oct
On Sat, Oct 1, 2016 at 4:41 PM, Simon Slavin wrote:
> According to a 2012 post from DRH, try this compilation option:
>
> -DSQLITE_WITHOUT_ZONEMALLOC
Another, probably better way would be -DOSATOMIC_USE_INLINED=1. That
will transparently substitute legacy atomic op interfaces with their
counterp
On 10/1/16, Judson Lester wrote:
> I understand that this project doesn't produce go-sqlite3, but the
> sqlite-bindings.c that project incorporates (and which is the origin of the
> deprecation warning) do seem to be part of this project. If that's not so,
> can you direct me to the true source so
According to a 2012 post from DRH, try this compilation option:
-DSQLITE_WITHOUT_ZONEMALLOC
Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Richard Hipp wrote:
> On 9/30/16, Judson Lester wrote:
>> vendor/github.com/mattn/go-sqlite3/sqlite3-binding.c:18709:17: warning:
>> 'OSAtomicCompareAndSwapPtrBarrier' is deprecated: first deprecated in macOS
>> 10.12 - Use atomic_compare_exchange_strong() from instead
>> [-Wdeprecated-declaratio
On 9/30/16, Judson Lester wrote:
> Using go-sqlite3, I get this warning with every build:
>
> # github.com/mattn/go-sqlite3
> vendor/github.com/mattn/go-sqlite3/sqlite3-binding.c:18709:17: warning:
> 'OSAtomicCompareAndSwapPtrBarrier' is deprecated: first deprecated in macOS
> 10.12 - Use atomic_c
Using go-sqlite3, I get this warning with every build:
# github.com/mattn/go-sqlite3
vendor/github.com/mattn/go-sqlite3/sqlite3-binding.c:18709:17: warning:
'OSAtomicCompareAndSwapPtrBarrier' is deprecated: first deprecated in macOS
10.12 - Use atomic_compare_exchange_strong() from instead
[-Wdep
fascinating... one can feed it a file of commands, or even a string of
commands, and the "Apply SQL" action will run against a specified or a
newly created SQLite database and format the output as plain text,
HTML or CSV.
--
Puneet Kishor http://www.punkish.org
Carbon Model http://carbonmodel.or
Worked cleanly now.
Thanks again.
Mel
On Wed, Oct 14, 2009 at 7:02 PM, William Kyngesburye
wrote:
> Odd, works fine here. ... ah, make sure you use the --disable-
> dependency-tracking option. The default dependency tracking does not
> work with multiple architectures. It's just a compilation
Odd, works fine here. ... ah, make sure you use the --disable-
dependency-tracking option. The default dependency tracking does not
work with multiple architectures. It's just a compilation process and
not using it has no effect on the generated code.
On Oct 14, 2009, at 7:42 PM, Melton Lo
I got a compile error when the 64bit flag was include. Worked fine if I
just use the 32bit flag.
Thanks for your help.
Mel
On Wed, Oct 14, 2009 at 6:01 PM, William Kyngesburye
wrote:
> Add this to your configure command (applies to most all configures):
>
> CFLAGS="-arch i386 -arch x86_64"
>
>
I got a compile error when the 64bit flag was include. Worked fine if I
just use the 32bit flag.
Thanks for your help.
Mel
On Wed, Oct 14, 2009 at 6:01 PM, William Kyngesburye
wrote:
> Add this to your configure command (applies to most all configures):
>
> CFLAGS="-arch i386 -arch x86_64"
>
>
Add this to your configure command (applies to most all configures):
CFLAGS="-arch i386 -arch x86_64"
On Oct 14, 2009, at 4:46 PM, Melton Low wrote:
> I am on a Mac laptop running Mac OS X 10.6.1 (Snow Leopard).
>
> Version of Sqlite I want to build is 3.6.19. When running 'configure
> --help'
I am on a Mac laptop running Mac OS X 10.6.1 (Snow Leopard).
Version of Sqlite I want to build is 3.6.19. When running 'configure
--help' I didn't find an option to set the build to 32bit. Is sqlite
automatically build as a 32bit app with 32bit libraries? Did I miss an
option?
Mel
I have successfully compiled the source for version 3.6.6.2 for Mac OS
X PowerPC that I have placed in a compressed tar file that I wouldn't
mind making available to be placed in the download section of the web
site. You only have Mac OS X Intel binary.
I created the tar flie from /usr and
On Dec 1, 2007, at 5:08 AM, [EMAIL PROTECTED] wrote:
The comment probably should read: "Needed to enable pthread
recursive mutexes *on Linux*".
The _XOPEN_SOURCE define is needed to fix compile-time problems.
If you didn't get a compile-time error, it is probably working.
Great, that's the
--- [EMAIL PROTECTED] wrote:
> Joe Wilson <[EMAIL PROTECTED]> wrote:
> > --- [EMAIL PROTECTED] wrote:
> > > The comment probably should read: "Needed to enable pthread
> > > recursive mutexes *on Linux*".
> >
> > Or more specifically, on old versions of Linux/GNU LIBC.
> >
> > Have you seen an
Joe Wilson <[EMAIL PROTECTED]> wrote:
> --- [EMAIL PROTECTED] wrote:
> > The comment probably should read: "Needed to enable pthread
> > recursive mutexes *on Linux*".
>
> Or more specifically, on old versions of Linux/GNU LIBC.
>
> Have you seen any recent Linux distros that need this macro d
--- [EMAIL PROTECTED] wrote:
> The comment probably should read: "Needed to enable pthread
> recursive mutexes *on Linux*".
Or more specifically, on old versions of Linux/GNU LIBC.
Have you seen any recent Linux distros that need this macro defined?
If so, maybe you could define it only for th
Peter Johnson <[EMAIL PROTECTED]> wrote:
> That's an improvement, using 3.5.3. I have to define __DARWIN__
> instead of __MACOS__ now, but at it least compiles without modifying
> any sources.
>
> (I wonder why the config stuff does set __DARWIN__)
>
> I still question whether or not I'm get
That's an improvement, using 3.5.3. I have to define __DARWIN__
instead of __MACOS__ now, but at it least compiles without modifying
any sources.
(I wonder why the config stuff does set __DARWIN__)
I still question whether or not I'm getting a thread safe build
though. If I define __DARW
On Nov 30, 2007, at 1:32 PM, [EMAIL PROTECTED] wrote:
Peter Johnson <[EMAIL PROTECTED]> wrote:
I'm running into a problem building SQLite 3.5.1 targeting a minimum
of Mac OS X 10.3, but building against the 10.4 (Universal) SDK.
I think this issue has been addressed in 3.5.3. Have
you tried
Peter Johnson <[EMAIL PROTECTED]> wrote:
> I'm running into a problem building SQLite 3.5.1 targeting a minimum
> of Mac OS X 10.3, but building against the 10.4 (Universal) SDK.
I think this issue has been addressed in 3.5.3. Have
you tried using the latest sources?
--
D. Richard Hipp <[EMAIL
I'm running into a problem building SQLite 3.5.1 targeting a minimum
of Mac OS X 10.3, but building against the 10.4 (Universal) SDK.
The problem is that the 10.4 SDK does name mangling on the
pthread_join symbol in some cases. Specifically, if the
_XOPEN_SOURCE symbol is defined, pthread_
At 11:32 AM +0600 2/15/06, Kirill wrote:
Whether will be SqlLite in the future and under Mac OS if there will
be that as soon?
SQLite runs under Mac OS X right now, and has for a long time. A
version is even bundled with X.4 Tiger. -- Darren Duncan
Whether will be SqlLite in the future and under Mac OS if there will be that as
soon?
samba filesystem does not support that style of locking API on Mac OS X.
Is there any known workarounds to get it to work correctly?
A time machine :-)
The SMB protocol does Windows style locking which has various
wierd and wonderful semantics. But they have nothing in common
with UNIX locking wh
[EMAIL PROTECTED] wrote:
On Tue, 4 Jan 2005, Steve Milner wrote:
Hello List,
I am having a problem with SQLite erroring out on Mac OS X. I am
using 3.0.8. The problem happens when it tries to access a
SAMBA/CIFS shared database. In my testing Windows to Linux and
Linux to Windows worked fine
On Tue, 4 Jan 2005, Steve Milner wrote:
Hello List,
I am having a problem with SQLite erroring out on Mac OS X. I am
using 3.0.8. The problem happens when it tries to access a SAMBA/CIFS
shared database. In my testing Windows to Linux and Linux to Windows
worked fine, but Mac to Windows fail
Ara.T.Howard wrote:
On Tue, 4 Jan 2005, Steve Milner wrote:
Hello List,
I am having a problem with SQLite erroring out on Mac OS X. I am
using 3.0.8. The problem happens when it tries to access a SAMBA/CIFS
shared database. In my testing Windows to Linux and Linux to Windows
worked fine, but Mac
On Tue, 4 Jan 2005, Steve Milner wrote:
Hello List,
I am having a problem with SQLite erroring out on Mac OS X. I am using 3.0.8.
The problem happens when it tries to access a SAMBA/CIFS shared database. In
my testing Windows to Linux and Linux to Windows worked fine, but Mac to
Windows fails wi
Hello List,
I am having a problem with SQLite erroring out on Mac OS X. I am using
3.0.8. The problem happens when it tries to access a SAMBA/CIFS shared
database. In my testing Windows to Linux and Linux to Windows worked
fine, but Mac to Windows fails with the following:
Traceback (most recen
On Nov 6, 2004, at 10:48 AM, Jeff Flowers wrote:
There has to it than just being under the GPL. After all, Emacs and
other GLPed software is included in Mac OS X. Maybe it is to prevent
people from accidently mixing GPLed and non-GPLed code?
There isn't any GPL'd software on the baseline user insta
>> So, Fink is no longer needed just for Readline if you have the
>> Developer Tools installed. :)
>
> That has always been the case -- Fink has never been needed.
Readline 4.x did not compile straight out of the tarball. The source
code needed a small modification, as documented on the SQLite W
On Nov 6, 2004, at 7:24 AM, Jeff Flowers wrote:
I don't know if this is already known but for any Mac OS X 10.3 users,
I
wanted to mention that Readline 5.0 now compiles out of the tarball,
using the normal "configure,make,make install" commands. I just
verified
this for myself by building Readli
I don't know if this is already known but for any Mac OS X 10.3 users, I
wanted to mention that Readline 5.0 now compiles out of the tarball,
using the normal "configure,make,make install" commands. I just verified
this for myself by building Readline 5.0 and SQLite 3.0.8 on my PowerMac
G4. I have
Tim Anderson wrote:
Using version 2.8.9 and OS X 10.2.8
I had no trouble compiling Sqlite, although if I enable-shared I get a
bus error on one of the tests (in make test).
FWIW, the relevant ticket is:
http://www.sqlite.org/cvstrac/tktview?tn=369
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 7
Using version 2.8.9 and OS X 10.2.8
I had no trouble compiling Sqlite, although if I enable-shared I get a
bus error on one of the tests (in make test). I have to disable shared
library support anyway because...
I had considerable difficulty compiling the Java wrapper at
http://www.ch-werner.de/j
45 matches
Mail list logo