www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ODBC component licenses

reply Steve Teale <steve.teale britseyeview.com> writes:
The libraries for unixODBC and for FreeTDS (communication with SQL 
Server) are LGPL.

Would a D ODBC driver that used these be compatible with Phobos?

Steve
Nov 09 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale  
<steve.teale britseyeview.com> wrote:


 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?


glibc, which dmd (and all Linux binaries) rely on is LGPL.  So if you are  
saying what I think you are saying, yes.  As long as the LGPL code is kept  
in a *separate* shared object, it is perfectly legal to link with it  
without infecting phobos' license.

-Steve
Nov 10 2011
next sibling parent Steve Teale <steve.teale britseyeview.com> writes:
On Thu, 10 Nov 2011 08:23:47 -0500, Steven Schveighoffer wrote:


 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale
 <steve.teale britseyeview.com> wrote:
 

 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?


 
 glibc, which dmd (and all Linux binaries) rely on is LGPL.  So if you
 are saying what I think you are saying, yes.  As long as the LGPL code
 is kept in a *separate* shared object, it is perfectly legal to link
 with it without infecting phobos' license.
 
 -Steve


I had wondered about the C library and how we got away with that.

I think that we can find a sql.h and sqlext.h to convert, so it sounds 
like we should be good. I was thinking for a moment that we might have to 
go protocol level to speak to SQL Server.

Steve
Nov 10 2011
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale
 
 <steve.teale britseyeview.com> wrote:

 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.
 
 Would a D ODBC driver that used these be compatible with Phobos?


 
 glibc, which dmd (and all Linux binaries) rely on is LGPL. So if you are
 saying what I think you are saying, yes. As long as the LGPL code is kept
 in a *separate* shared object, it is perfectly legal to link with it
 without infecting phobos' license.


Though the fact that it needs to be in a separate shared object does make it 
problematic to stick in Phobos, since Phobos is just one shared object. So, if 
he's looking to put it _in_ Phobos, then I don't think that we can do that 
with the current setup.

- Jonathan M Davis
Nov 10 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale

 <steve.teale britseyeview.com> wrote:

 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?


 glibc, which dmd (and all Linux binaries) rely on is LGPL. So if you are
 saying what I think you are saying, yes. As long as the LGPL code is  
 kept
 in a *separate* shared object, it is perfectly legal to link with it
 without infecting phobos' license.


 Though the fact that it needs to be in a separate shared object does  
 make it
 problematic to stick in Phobos, since Phobos is just one shared object.  
 So, if
 he's looking to put it _in_ Phobos, then I don't think that we can do  
 that
 with the current setup.


My understanding is that the FreeTDS is its *own* shared object (installed  
separately).  We cannot include LGPL code in phobos.lib.

BTW, phobos is not a shared object (yet).

-Steve
Nov 10 2011
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, November 10, 2011 10:29 Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis <jmdavisProg gmx.com>
 
 wrote:

 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale
 
 <steve.teale britseyeview.com> wrote:

 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.
 
 Would a D ODBC driver that used these be compatible with Phobos?


 
 glibc, which dmd (and all Linux binaries) rely on is LGPL. So if you are
 saying what I think you are saying, yes. As long as the LGPL code is
 kept
 in a *separate* shared object, it is perfectly legal to link with it
 without infecting phobos' license.


 
 Though the fact that it needs to be in a separate shared object does
 make it
 problematic to stick in Phobos, since Phobos is just one shared object.
 So, if
 he's looking to put it _in_ Phobos, then I don't think that we can do
 that
 with the current setup.


 
 My understanding is that the FreeTDS is its *own* shared object (installed
 separately). We cannot include LGPL code in phobos.lib.


I'm afraid that I've never even heard of TDS, so I'm not quite sure how that 
relates. We theoretically _could_ provide LGPL code in a separate library, but 
we don't do anything like that now.


 BTW, phobos is not a shared object (yet).


LOL. True. I didn't think that statement through enough. It's a library, but 
not a shared one.

- Jonathan M Davis
Nov 10 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 10 Nov 2011 13:36:38 -0500, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 On Thursday, November 10, 2011 10:29 Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis  
 <jmdavisProg gmx.com>

 wrote:

 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale

 <steve.teale britseyeview.com> wrote:

 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?


 glibc, which dmd (and all Linux binaries) rely on is LGPL. So if you  




 are

 saying what I think you are saying, yes. As long as the LGPL code is
 kept
 in a *separate* shared object, it is perfectly legal to link with it
 without infecting phobos' license.


 Though the fact that it needs to be in a separate shared object does
 make it
 problematic to stick in Phobos, since Phobos is just one shared  


 object.

 So, if
 he's looking to put it _in_ Phobos, then I don't think that we can do
 that
 with the current setup.


 My understanding is that the FreeTDS is its *own* shared object  
 (installed
 separately). We cannot include LGPL code in phobos.lib.


 I'm afraid that I've never even heard of TDS, so I'm not quite sure how  
 that
 relates. We theoretically _could_ provide LGPL code in a separate  
 library, but
 we don't do anything like that now.


I wasn't sure so I looked it up:

http://www.freetds.org/faq.html#where.is.libtds.so

Apparently, you can still have LGPL code that is statically linked?  I'm  
not sure now how that works, my understanding was always that LGPL works  
because of shared objects.

-Steve
Nov 10 2011
parent reply Steve Teale <steve.teale britseyeview.com> writes:
On Thu, 10 Nov 2011 13:54:04 -0500, Steven Schveighoffer wrote:


 On Thu, 10 Nov 2011 13:36:38 -0500, Jonathan M Davis
 <jmdavisProg gmx.com> wrote:
 

 On Thursday, November 10, 2011 10:29 Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis
 <jmdavisProg gmx.com>

 wrote:

 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale

 <steve.teale britseyeview.com> wrote:

 The libraries for unixODBC and for FreeTDS (communication with
 SQL Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?


 glibc, which dmd (and all Linux binaries) rely on is LGPL. So if
 you




 are

 saying what I think you are saying, yes. As long as the LGPL code
 is kept
 in a *separate* shared object, it is perfectly legal to link with
 it without infecting phobos' license.


 Though the fact that it needs to be in a separate shared object does
 make it
 problematic to stick in Phobos, since Phobos is just one shared


 object.

 So, if
 he's looking to put it _in_ Phobos, then I don't think that we can
 do that
 with the current setup.


 My understanding is that the FreeTDS is its *own* shared object
 (installed
 separately). We cannot include LGPL code in phobos.lib.


 I'm afraid that I've never even heard of TDS, so I'm not quite sure how
 that
 relates. We theoretically _could_ provide LGPL code in a separate
 library, but
 we don't do anything like that now.


 
 I wasn't sure so I looked it up:
 
 http://www.freetds.org/faq.html#where.is.libtds.so
 
 Apparently, you can still have LGPL code that is statically linked?  I'm
 not sure now how that works, my understanding was always that LGPL works
 because of shared objects.
 
 -Steve


I've just done my first thing in the morning thing again with Pan and 
deleted one of your postings in the thread.

So lots of things can't be included in Phobos because it is one big 
static library, right?

If you don't include some Phobos module in your app, the linker still 
wants to pull in the unsatisfied externals for that module even though 
they will not be used?

I thought that a library was an archive, and that linkers just pulled in 
the object files that were required by the app.

If that's not the case, then having D able to easily generate DLLs and 
shared libraries would seem to be priority number one.

Clearly we don't have any philosophical objection to using external 
libraries from Phobos - std.socket points out that you have to link with 
the Windows sockets library. Or is that one of the old libraries that 
Microsoft lets Walter use?

Steve
Nov 10 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-11-11 05:25, Steve Teale wrote:


 I've just done my first thing in the morning thing again with Pan and
 deleted one of your postings in the thread.

 So lots of things can't be included in Phobos because it is one big
 static library, right?

 If you don't include some Phobos module in your app, the linker still
 wants to pull in the unsatisfied externals for that module even though
 they will not be used?


No, it won't. Tango uses external libraries, libz and libssl. You have 
to explicitly link those libraries when you use those modules, but only 
for those modules and no other modules.


 I thought that a library was an archive, and that linkers just pulled in
 the object files that were required by the app.

 If that's not the case, then having D able to easily generate DLLs and
 shared libraries would seem to be priority number one.

 Clearly we don't have any philosophical objection to using external
 libraries from Phobos - std.socket points out that you have to link with
 the Windows sockets library. Or is that one of the old libraries that
 Microsoft lets Walter use?

 Steve



-- 
/Jacob Carlborg
Nov 10 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 10 Nov 2011 23:25:38 -0500, Steve Teale  
<steve.teale britseyeview.com> wrote:


 On Thu, 10 Nov 2011 13:54:04 -0500, Steven Schveighoffer wrote:


 On Thu, 10 Nov 2011 13:36:38 -0500, Jonathan M Davis
 <jmdavisProg gmx.com> wrote:


 On Thursday, November 10, 2011 10:29 Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis
 <jmdavisProg gmx.com>

 wrote:

 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale

 <steve.teale britseyeview.com> wrote:

 The libraries for unixODBC and for FreeTDS (communication with
 SQL Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?


 glibc, which dmd (and all Linux binaries) rely on is LGPL. So if
 you




 are

 saying what I think you are saying, yes. As long as the LGPL code
 is kept
 in a *separate* shared object, it is perfectly legal to link with
 it without infecting phobos' license.


 Though the fact that it needs to be in a separate shared object does
 make it
 problematic to stick in Phobos, since Phobos is just one shared


 object.

 So, if
 he's looking to put it _in_ Phobos, then I don't think that we can
 do that
 with the current setup.


 My understanding is that the FreeTDS is its *own* shared object
 (installed
 separately). We cannot include LGPL code in phobos.lib.


 I'm afraid that I've never even heard of TDS, so I'm not quite sure how
 that
 relates. We theoretically _could_ provide LGPL code in a separate
 library, but
 we don't do anything like that now.


 I wasn't sure so I looked it up:

 http://www.freetds.org/faq.html#where.is.libtds.so

 Apparently, you can still have LGPL code that is statically linked?  I'm
 not sure now how that works, my understanding was always that LGPL works
 because of shared objects.

 -Steve


 I've just done my first thing in the morning thing again with Pan and
 deleted one of your postings in the thread.


opera :)

You can always use webnews to look for posts that you accidentally deleted:

http://www.digitalmars.com/webnews/newsgroups.php

Or use the archive (from digitalmars.com website), but this seems to lag  
the actual posts by some period of time.


 So lots of things can't be included in Phobos because it is one big
 static library, right?


I don't know.  When I said I'm not sure, it wasn't a euphemism for  
thinking it wouldn't work, I literally am not sure.  Maybe it can be done,  
but the licensing issues have to be worked out, even if it doesn't taint  
the rest of phobos.

Clearly if someone is to ship a program which uses libfreetds.a, they  
would need to provide source code for the library.  Is this something we  
want to require users of phobos + SQL server to do?  I don't know.

I'm just very surprised they use static libs (and it looks from that post  
like a recent change).


 If you don't include some Phobos module in your app, the linker still
 wants to pull in the unsatisfied externals for that module even though
 they will not be used?


There are some technical issues.  For example, if phobos depends on a  
library, then that library has to come *after* phobos.  In a recent update  
to ubuntu, the link order became very important, and it broke all dmd  
versions that had std.datetime, because it requires the librt.so library.   
Therefore the link line had to be -lphobos -lrt in that order.  However,  
dmd *always* tacks on -lphobos at the end of the link line, regardless of  
what is in configuration or command line.  However, certain libraries  
phobos depends on are added after -lphobos, such as -lm and -lpthread.   
Walter fixed the problem for 2.056 by tacking on -lrt as well.  This  
solution could *not* be used for freetds because it's not a default  
install in any modern OS (seeing as how it's a static lib, it would only  
be installed if you were interested in developing with it).

Even though the linker will probably ignore the lib if you don't use any  
symbols from it, I don't think it will work if it can't *find* the lib.

However, if phobos' database API is an extendable *framework*, then one  
could define 3rd party libs that add non-compatible licensed code to be  
used when needed.  It's far from an ideal situation, but licensing is a  
real issue that must be worked around.

I'll add that I am not a lawyer and I'm not 100% positive of the path we  
need to take.


 If that's not the case, then having D able to easily generate DLLs and
 shared libraries would seem to be priority number one.


I have felt this for a long time.  As long as dmd cannot easily generate  
native DLLs, it will be a toy language.


 Clearly we don't have any philosophical objection to using external
 libraries from Phobos - std.socket points out that you have to link with
 the Windows sockets library. Or is that one of the old libraries that
 Microsoft lets Walter use?


First, that is an OS-provided library that is not GPL'd or LGPL'd.  You  
are free to use it in whatever code you wish, and it is *always* installed  
on every windows OS (starting with windows 98 I think?)

Second, you may be confused by the linking process on Windows.  WS2_32.lib  
is *not* a static library, it's a linker file.  In windows, you need this  
linker file in order to link against a DLL.

-Steve
Nov 11 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-11-10 19:36, Jonathan M Davis wrote:

 I'm afraid that I've never even heard of TDS, so I'm not quite sure how that
 relates. We theoretically _could_ provide LGPL code in a separate library, but
 we don't do anything like that now.


TDS - Tabular Data Stream, is the protocol Microsoft uses for SQL 
Server, also used by Sybase. FreeTDS would be the free implementation of 
that protocol and it uses the LGPL license.

ODBC is a database independent layer. When ODBC connects to SQL Server 
it uses the FreeTDS library.

It's not necessary to use ODBC to connect to SQL Server, FreeTDS can be 
used on its own (don't know how low level FreeTDS actually is).

I would recommend creating bindings to FreeTDS for connecting to SQL 
Server. Of curse, an ODBC driver would be good to have as well.


 BTW, phobos is not a shared object (yet).


 LOL. True. I didn't think that statement through enough. It's a library, but
 not a shared one.

 - Jonathan M Davis



-- 
/Jacob Carlborg
Nov 10 2011
prev sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis wrote:


 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale
 
 <steve.teale britseyeview.com> wrote:

 The libraries for unixODBC and for FreeTDS (communication with SQL




 Though the fact that it needs to be in a separate shared object does
 make it problematic to stick in Phobos, since Phobos is just one shared
 object. So, if he's looking to put it _in_ Phobos, then I don't think
 that we can do that with the current setup.
 
 - Jonathan M Davis


So what about etc.curl for instance?

Steve
Nov 10 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, November 10, 2011 19:13:00 Steve Teale wrote:

 On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis wrote:

 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale
 
 <steve.teale britseyeview.com> wrote:

 The libraries for unixODBC and for FreeTDS (communication with SQL




 
 Though the fact that it needs to be in a separate shared object does
 make it problematic to stick in Phobos, since Phobos is just one shared
 object. So, if he's looking to put it _in_ Phobos, then I don't think
 that we can do that with the current setup.
 
 - Jonathan M Davis


 
 So what about etc.curl for instance?


It's not LGPL.

- Jonathan M Davis
Nov 10 2011
parent reply Steve Teale <steve.teale britseyeview.com> writes:
On Thu, 10 Nov 2011 12:39:28 -0800, Jonathan M Davis wrote:


 On Thursday, November 10, 2011 19:13:00 Steve Teale wrote:

 On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis wrote:

 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale
 
 <steve.teale britseyeview.com> wrote:

 The libraries for unixODBC and for FreeTDS (communication with SQL




 
 Though the fact that it needs to be in a separate shared object does
 make it problematic to stick in Phobos, since Phobos is just one
 shared object. So, if he's looking to put it _in_ Phobos, then I
 don't think that we can do that with the current setup.
 
 - Jonathan M Davis


 
 So what about etc.curl for instance?





 It's not LGPL.


Steve thought linking to LGPL was not a problem - we link to glibc

But it presumably has to be linked to a library?

Steve
Nov 10 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 10 Nov 2011 23:01:57 -0500, Steve Teale  
<steve.teale britseyeview.com> wrote:


 On Thu, 10 Nov 2011 12:39:28 -0800, Jonathan M Davis wrote:


 On Thursday, November 10, 2011 19:13:00 Steve Teale wrote:

 On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis wrote:

 On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale

 <steve.teale britseyeview.com> wrote:

 The libraries for unixODBC and for FreeTDS (communication with SQL




 Though the fact that it needs to be in a separate shared object does
 make it problematic to stick in Phobos, since Phobos is just one
 shared object. So, if he's looking to put it _in_ Phobos, then I
 don't think that we can do that with the current setup.

 - Jonathan M Davis


 So what about etc.curl for instance?





 It's not LGPL.


 Steve thought linking to LGPL was not a problem - we link to glibc

 But it presumably has to be linked to a library?


I'm 100% sure linking to an LGPL shared object is fine for Phobos.

I'm not sure at all linking to an LGPL static library is fine for Phobos.   
There are both legal and philosophical issues to resolve.  From what I've  
read online, it appears to be legal with certain versions of the LGPL,  
maybe all of them.

BTW, I started reading this post thinking you were referring to yourself  
in the 3rd person :)

-Steve
Nov 11 2011
prev sibling parent reply Dejan Lekic <dejan.lekic tiscali.co.uk> writes:
On 10/11/11 05:55, Steve Teale wrote:

 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?

 Steve


I would strongly advice any DB driver go into a separate library instead 
of Phobos. Too many unneeded modules are in Phobos already and more 
modules that do not belong in Phobos are about to be accepted...

Possibly all DB drivers could go into one, or separate (better, so one 
can load them when needed) libraries. If that is the case, the author 
can use any license he or she likes.

Kind regards
Nov 10 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, November 10, 2011 19:50:03 Dejan Lekic wrote:

 On 10/11/11 05:55, Steve Teale wrote:

 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.
 
 Would a D ODBC driver that used these be compatible with Phobos?
 
 Steve


 
 I would strongly advice any DB driver go into a separate library instead
 of Phobos. Too many unneeded modules are in Phobos already and more
 modules that do not belong in Phobos are about to be accepted...


Like what?


 Possibly all DB drivers could go into one, or separate (better, so one
 can load them when needed) libraries. If that is the case, the author
 can use any license he or she likes.


It's going to have to be set up such that 3rd party DB drivers can be used, 
but the more of them that we can put in Phobos, the better, since it makes it 
easier to find and use them.

The entire issue here is licensing, not whether we _want_ to stick it in 
Phobos.

- Jonathan M Davis
Nov 10 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/10/11 1:50 PM, Dejan Lekic wrote:

 On 10/11/11 05:55, Steve Teale wrote:

 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?

 Steve


 I would strongly advice any DB driver go into a separate library instead
 of Phobos. Too many unneeded modules are in Phobos already and more
 modules that do not belong in Phobos are about to be accepted...


I thought the main concern was that there's too little stuff in Phobos, 
and that growth is good. Seems like whatever we do we won't please everyone.

Andrei
Nov 10 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 10 Nov 2011 16:06:56 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 11/10/11 1:50 PM, Dejan Lekic wrote:

 On 10/11/11 05:55, Steve Teale wrote:

 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?

 Steve


 I would strongly advice any DB driver go into a separate library instead
 of Phobos. Too many unneeded modules are in Phobos already and more
 modules that do not belong in Phobos are about to be accepted...


 I thought the main concern was that there's too little stuff in Phobos,  
 and that growth is good. Seems like whatever we do we won't please  
 everyone.


Well, one concern I would have is making *phobos* dependent on these  
libraries, which may not be needed (or installed).

Note that in recent times, dmd failed to compile any programs Ubuntu  
because of new linking rules.  The solution was to add -lrt to the dmd  
source code that generates the link line.

Is that the same solution for FreeTDS?  What if FreeTDS isn't installed  
(it typically is not)?  What if you don't use the database system, why  
should you have to link against FreeTDS if it's not being used?

I'd much rather have the database subsystem *framework* be a part of  
phobos, and the actual implementations be defined as 3rd party libs.  Just  
 from a practical point of view.

-Steve
Nov 10 2011
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, November 10, 2011 13:49 Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 16:06:56 -0500, Andrei Alexandrescu
 
 <SeeWebsiteForEmail erdani.org> wrote:

 On 11/10/11 1:50 PM, Dejan Lekic wrote:

 On 10/11/11 05:55, Steve Teale wrote:

 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.
 
 Would a D ODBC driver that used these be compatible with Phobos?
 
 Steve


 
 I would strongly advice any DB driver go into a separate library instead
 of Phobos. Too many unneeded modules are in Phobos already and more
 modules that do not belong in Phobos are about to be accepted...


 
 I thought the main concern was that there's too little stuff in Phobos,
 and that growth is good. Seems like whatever we do we won't please
 everyone.


 
 Well, one concern I would have is making *phobos* dependent on these
 libraries, which may not be needed (or installed).
 
 Note that in recent times, dmd failed to compile any programs Ubuntu
 because of new linking rules. The solution was to add -lrt to the dmd
 source code that generates the link line.
 
 Is that the same solution for FreeTDS? What if FreeTDS isn't installed
 (it typically is not)? What if you don't use the database system, why
 should you have to link against FreeTDS if it's not being used?
 
 I'd much rather have the database subsystem *framework* be a part of
 phobos, and the actual implementations be defined as 3rd party libs. Just
 from a practical point of view.


Yeah. Adding functionality to Phobos which is pure D is generally a good thing 
(though stuff which really isn't generally useful obviously shouldn't be in 
there). But adding stuff that requires additional dependencies is far more 
iffy. If the module is really self-contained and you can get away with using 
Phobos without linking in the library that it needs as long as you don't use 
it, then it's not necessarily a big deal. But if it's going to require that 
everyone using Phobos link it in and it's not standard on all systems, then it 
needs a really solid reason for being in Phobos. And if we get in a situation 
where we need to add extra linking commands to dmd itself (as we had to with 
librt) for each such library, then that becomes undesirable very quickly IMHO.

And given the licensing issues that we're seeing with the DB stuff, that lends 
even more credence to the idea of just having them all as separate modules 
with just the framework being in Phobos. It would be nice to have them in 
Phobos, but if we're going to have licensing problems and/or dependency 
problems because it, then they shouldn't be in Phobos proper.

- Jonathan M Davis
Nov 10 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-10 23:24, Jonathan M Davis wrote:


 Yeah. Adding functionality to Phobos which is pure D is generally a good thing
 (though stuff which really isn't generally useful obviously shouldn't be in
 there). But adding stuff that requires additional dependencies is far more
 iffy. If the module is really self-contained and you can get away with using
 Phobos without linking in the library that it needs as long as you don't use
 it, then it's not necessarily a big deal. But if it's going to require that
 everyone using Phobos link it in and it's not standard on all systems, then it
 needs a really solid reason for being in Phobos. And if we get in a situation
 where we need to add extra linking commands to dmd itself (as we had to with
 librt) for each such library, then that becomes undesirable very quickly IMHO.


If dlopen is used to load a dynamic library then there shouldn't be any 
problem. It will be automatically loaded and only when needed.

-- 
/Jacob Carlborg
Nov 11 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 11 Nov 2011 05:49:32 -0500, Jacob Carlborg <doob me.com> wrote:


 On 2011-11-10 23:24, Jonathan M Davis wrote:


 Yeah. Adding functionality to Phobos which is pure D is generally a  
 good thing
 (though stuff which really isn't generally useful obviously shouldn't  
 be in
 there). But adding stuff that requires additional dependencies is far  
 more
 iffy. If the module is really self-contained and you can get away with  
 using
 Phobos without linking in the library that it needs as long as you  
 don't use
 it, then it's not necessarily a big deal. But if it's going to require  
 that
 everyone using Phobos link it in and it's not standard on all systems,  
 then it
 needs a really solid reason for being in Phobos. And if we get in a  
 situation
 where we need to add extra linking commands to dmd itself (as we had to  
 with
 librt) for each such library, then that becomes undesirable very  
 quickly IMHO.


 If dlopen is used to load a dynamic library then there shouldn't be any  
 problem. It will be automatically loaded and only when needed.


The subject of this discussion (FreeTDS) apparently only comes in static  
library form (unless we want to build and support dynamic libraries of it).

-Steve
Nov 11 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-11 14:06, Steven Schveighoffer wrote:

 On Fri, 11 Nov 2011 05:49:32 -0500, Jacob Carlborg <doob me.com> wrote:

 If dlopen is used to load a dynamic library then there shouldn't be
 any problem. It will be automatically loaded and only when needed.


 The subject of this discussion (FreeTDS) apparently only comes in static
 library form (unless we want to build and support dynamic libraries of it).

 -Steve



Hmm, I have FreeTDS installed as a dynamic library and I'm using it via 
Ruby on Rails. But I can see on the freetds FAQ page that it doesn't 
provide a dynamic library any more. I didn't know about that.

It seems one should have some kind of client library, which I assume can 
be a dynamic library.

-- 
/Jacob Carlborg
Nov 11 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 11 Nov 2011 10:32:00 -0500, Jacob Carlborg <doob me.com> wrote:


 On 2011-11-11 14:06, Steven Schveighoffer wrote:

 On Fri, 11 Nov 2011 05:49:32 -0500, Jacob Carlborg <doob me.com> wrote:

 If dlopen is used to load a dynamic library then there shouldn't be
 any problem. It will be automatically loaded and only when needed.


 The subject of this discussion (FreeTDS) apparently only comes in static
 library form (unless we want to build and support dynamic libraries of  
 it).

 -Steve



 Hmm, I have FreeTDS installed as a dynamic library and I'm using it via  
 Ruby on Rails. But I can see on the freetds FAQ page that it doesn't  
 provide a dynamic library any more. I didn't know about that.

 It seems one should have some kind of client library, which I assume can  
 be a dynamic library.


I think the approach we should support is defining a framework in phobos,  
and then implementations in external libs.  These external libs don't have  
to be dynamic ones.

-Steve
Nov 11 2011
prev sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
 The subject of this discussion (FreeTDS) apparently only comes in static
 library form (unless we want to build and support dynamic libraries of
 it).
 
 -Steve


Well, the one I downloaded a couple of days ago is a .so, and I'm not 
linking to that anyway, but to libodbc.so (part of unixODBC). The FreeTDS 
lib must be dynamically loaded by unixODBC, so given that the two are 
like hand in glove, it's difficult to see how they would change it to 
a .a.
Nov 11 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 11 Nov 2011 13:41:45 -0500, Steve Teale  
<steve.teale britseyeview.com> wrote:


 The subject of this discussion (FreeTDS) apparently only comes in static
 library form (unless we want to build and support dynamic libraries of
 it).

 -Steve


 Well, the one I downloaded a couple of days ago is a .so, and I'm not
 linking to that anyway, but to libodbc.so (part of unixODBC). The FreeTDS
 lib must be dynamically loaded by unixODBC, so given that the two are
 like hand in glove, it's difficult to see how they would change it to
 a .a.


If it's a .so, and you are using a wrapper library, I think it should be  
fine license-wise.  But there is still the issue of making phobos  
dependent on a not-so-common lib (not everyone has unixODBC installed on  
their system).

-Steve
Nov 11 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-10 22:49, Steven Schveighoffer wrote:

 On Thu, 10 Nov 2011 16:06:56 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 11/10/11 1:50 PM, Dejan Lekic wrote:

 On 10/11/11 05:55, Steve Teale wrote:

 The libraries for unixODBC and for FreeTDS (communication with SQL
 Server) are LGPL.

 Would a D ODBC driver that used these be compatible with Phobos?

 Steve


 I would strongly advice any DB driver go into a separate library instead
 of Phobos. Too many unneeded modules are in Phobos already and more
 modules that do not belong in Phobos are about to be accepted...


 I thought the main concern was that there's too little stuff in
 Phobos, and that growth is good. Seems like whatever we do we won't
 please everyone.


 Well, one concern I would have is making *phobos* dependent on these
 libraries, which may not be needed (or installed).

 Note that in recent times, dmd failed to compile any programs Ubuntu
 because of new linking rules. The solution was to add -lrt to the dmd
 source code that generates the link line.

 Is that the same solution for FreeTDS? What if FreeTDS isn't installed
 (it typically is not)? What if you don't use the database system, why
 should you have to link against FreeTDS if it's not being used?

 I'd much rather have the database subsystem *framework* be a part of
 phobos, and the actual implementations be defined as 3rd party libs.
 Just from a practical point of view.

 -Steve


With Tango you need to explicitly link to the third party libraries it 
uses, like libz and libssl.

-- 
/Jacob Carlborg
Nov 10 2011
next sibling parent Jude Young <10equals2 gmail.com> writes:
 I'd much rather have the database subsystem *framework* be a part of
 phobos, and the actual implementations be defined as 3rd party libs.
 Just from a practical point of view.




Wait, wasn't that the point of CAPI/Deimos?  It seems that there is a 
bit of overlap here....
Nov 10 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, November 11, 2011 01:41:12 Jude Young wrote:

 I'd much rather have the database subsystem *framework* be a part of
 phobos, and the actual implementations be defined as 3rd party libs.
 Just from a practical point of view.




 
 Wait, wasn't that the point of CAPI/Deimos?  It seems that there is a
 bit of overlap here....


No. Deimos is for C headers which have been translated to D. What we're 
talking about here are modules which provide engines for Phobos' database 
framework. There will be modules for various databases - sqlite, postgres, 
etc. Those modules will be written in D using the API that the database 
framework requires, and they will _use_ C headers which were translated to D 
(possibly in Deimos), but they will not _be_ such headers, so they're not part 
of Deimos. Whether they will end up in Phobos proper or not will depend on 
stuff like what licenses they have.

- Jonathan M Davis
Nov 10 2011
parent Steve Teale <steve.teale britseyeview.com> writes:
 No. Deimos is for C headers which have been translated to D. What we're
 talking about here are modules which provide engines for Phobos'
 database framework. There will be modules for various databases -
 sqlite, postgres, etc. Those modules will be written in D using the API
 that the database framework requires, and they will _use_ C headers
 which were translated to D (possibly in Deimos), but they will not _be_
 such headers, so they're not part of Deimos. Whether they will end up in
 Phobos proper or not will depend on stuff like what licenses they have.
 
 - Jonathan M Davis


Jonathan,

Agreed, that's how I understand the situation, but it seems to be 
increasingly clear that this is not sufficient. If there are to be easy 
to use D components, Deimos should be a two-level thing, with the 
translated headers in the lower layer, and the sort of stuff we've been 
talking about in an upper layer.

The alternative for the database stuff is to do everything where there is 
a licensing issue at protocol level. I think this is the way PHP has gone.

If I bit the bullet and did TDS, we'd be able to cover MySQL (protocol), 
Postgres (I'm assuming their license is sufficiently liberal), SQLite (no 
license), SQL Server (protocol), and SyBase (protocol).

At that point we could probably relax. Oracle, DB2, and whoever would 
probably contribute components in time.

This is making my head hurt, especially taken with a dose of trying to do 
a decent translation of ODBC header files to D!

Steve
Nov 11 2011