Re: [sqlite] Mac OS Sierra deprecation in bindings

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

Re: [sqlite] Mac OS Sierra deprecation in bindings

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

Re: [sqlite] Mac OS Sierra deprecation in bindings

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

Re: [sqlite] Mac OS Sierra deprecation in bindings

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

Re: [sqlite] Mac OS Sierra deprecation in bindings

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

Re: [sqlite] Mac OS Sierra deprecation in bindings

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

Re: [sqlite] Mac OS Sierra deprecation in bindings

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

Re: [sqlite] Mac OS Sierra deprecation in bindings

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,

Re: [sqlite] Mac OS Sierra deprecation in bindings

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

Re: [sqlite] Mac OS Sierra deprecation in bindings

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

Re: [sqlite] Mac OS Sierra deprecation in bindings

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

Re: [sqlite] Mac OS Sierra deprecation in bindings

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

Re: [sqlite] Mac OS Sierra deprecation in bindings

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 >

[sqlite] Mac OS Sierra deprecation in bindings

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

[sqlite] Mac OS X Automator works on SQLite db

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

Re: [sqlite] Mac OS Snow Leopard 32bit vs 64bit

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.

Re: [sqlite] Mac OS Snow Leopard 32bit vs 64bit

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

Re: [sqlite] Mac OS Snow Leopard 32bit vs 64bit

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

Re: [sqlite] Mac OS Snow Leopard 32bit vs 64bit

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 >

[sqlite] Mac OS Snow Leopard 32bit vs 64bit

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

[sqlite] Mac OS X PowerPC Binary Available

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

Re: [sqlite] Mac OS X name mangling

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

Re: [sqlite] Mac OS X name mangling

--- [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

Re: [sqlite] Mac OS X name mangling

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

Re: [sqlite] Mac OS X name mangling

--- [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

Re: [sqlite] Mac OS X name mangling

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

Re: [sqlite] Mac OS X name mangling

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

Re: [sqlite] Mac OS X name mangling

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

Re: [sqlite] Mac OS X name mangling

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

[sqlite] Mac OS X name mangling

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,

Re: [sqlite] Mac OS

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

[sqlite] Mac OS

Whether will be SqlLite in the future and under Mac OS if there will be that as soon?

Re: [sqlite] Mac OS X and SQLite Locking

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

Re: [sqlite] Mac OS X and SQLite Locking

[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

Re: [sqlite] Mac OS X and SQLite Locking

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

Re: [sqlite] Mac OS X and SQLite Locking

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

[sqlite] Mac OS X and SQLite Locking

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

Re: [sqlite] Mac OS X, Readline 5.0, and SQLite

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

Re: [sqlite] Mac OS X, Readline 5.0, and SQLite

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

Re: [sqlite] Mac OS X, Readline 5.0, and SQLite

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

[sqlite] Mac OS X, Readline 5.0, and SQLite

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