On Mon, Dec 15, 2008 at 09:51:16PM +, John Levon wrote:
> On Mon, Dec 15, 2008 at 09:32:03PM +, Daniel P. Berrange wrote:
>
> > > It's actually not clear to me why some of these are even in the version
> > > script. For example, why is brSetEnableSTP() there?
> >
> > It is used from the n
On Mon, Dec 15, 2008 at 09:32:03PM +, Daniel P. Berrange wrote:
> > It's actually not clear to me why some of these are even in the version
> > script. For example, why is brSetEnableSTP() there?
>
> It is used from the network_driver.c file, and that is linked to the
> daemon
Hmm I'd missed
On Mon, Dec 15, 2008 at 08:50:33PM +, John Levon wrote:
> On Sat, Dec 13, 2008 at 06:19:52PM +, Daniel P. Berrange wrote:
>
> > > I think the solution to the latter is to provide stubs that return
> > > failure codes for every symbol that can be ./configured out. So we'd
> > > introduce a
On Sat, Dec 13, 2008 at 06:19:52PM +, Daniel P. Berrange wrote:
> > I think the solution to the latter is to provide stubs that return
> > failure codes for every symbol that can be ./configured out. So we'd
> > introduce a stubs.c file that has these for everything, and compile each
> > of th
On Sat, Dec 13, 2008 at 05:03:33PM +, John Levon wrote:
>
> The current version script refers to symbols that don't exist in the
> code. What is the purpose of this? The Solaris linker (quite correctly,
> I think) generates hanging references to such symbols.
That's a bug - can you tell me wh
The current version script refers to symbols that don't exist in the
code. What is the purpose of this? The Solaris linker (quite correctly,
I think) generates hanging references to such symbols.
If it's just for documentation, such symbols should be commented out in
the script.
But there is ano
