On Thu, 10 Nov 2011 23:25:38 -0500, Steve Teale
<[email protected]> 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
<[email protected]> wrote:
On Thursday, November 10, 2011 10:29 Steven Schveighoffer wrote:
On Thu, 10 Nov 2011 13:10:26 -0500, Jonathan M Davis
<[email protected]>
wrote:
> On Thursday, November 10, 2011 05:23 Steven Schveighoffer wrote:
>> On Thu, 10 Nov 2011 00:55:01 -0500, Steve Teale
>>
>> <[email protected]> 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
