winebuild incompatibility with binutils-2.13.90.0.20

[Piotr Pawłow]

Hi,

There is a change in "nm -u" output format in the new binutils, now it 
outputs "U " before every symbol name. It looks like this:

$ nm -u d3d8.dll.tmp.o
         U cos
         U CreateDCA
         U DeleteDC
         U ExtEscape
         U GetClientRect
         U GetDC
         U GetDesktopWindow
         U GetDeviceCaps
         U GetModuleHandleA
         U GetProcAddress
         U GetPropA
(...)

Winebuild parser is not prepared for that. It does not find proper 
symbol names, creates spec.c files with no imports, and the result is 
that linking fails on unresolved symbols, as reported in "--with-nptl 
and glibc-2.3.2" thread.

A quick fix:

Index: tools/winebuild/import.c
===================================================================
RCS file: /home/wine/wine/tools/winebuild/import.c,v
retrieving revision 1.48
diff -r1.48 import.c
664a665,667
> if (*p == 'U') {
>       if (p[1] == ' ') p+=2;
>   }

Shouldn't winebuild, however, use libbfd where available, 
instead of relying on nm output?

-- 
 Piotr Pawłow
 mailto:pp(a)siedziba.pl

[Dmitry Timoshkov]

"Piotr PawЁow" <pp(a)siedziba.pl> wrote:
> Shouldn't winebuild, however, use libbfd where available,
> instead of relying on nm output?

AFAIK libbfd is GPL'ed, i.e. has an incompatible license.

--
Dmitry.

[Mike Hearn]

Why do we care about the L part of the LGPL for the tools? For the
libraries it's clearly important, but for the setup/build tools?

On Thu, 2003-04-10 at 06:18, Dmitry Timoshkov wrote:
> "Piotr PawЁow" <pp(a)siedziba.pl> wrote:
> > Shouldn't winebuild, however, use libbfd where available,
> > instead of relying on nm output?
>
> AFAIK libbfd is GPL'ed, i.e. has an incompatible license.
>
> --
> Dmitry.

[Dmitry Timoshkov]

"Mike Hearn" <mike(a)theoretic.com> wrote:
> Why do we care about the L part of the LGPL for the tools? For the
> libraries it's clearly important, but for the setup/build tools?

Because libbfd is a library. See the quote below.
> > "Piotr PawЁow" <pp(a)siedziba.pl> wrote:
> > > Shouldn't winebuild, however, use libbfd where available,
> > > instead of relying on nm output?
> >
> > AFAIK libbfd is GPL'ed, i.e. has an incompatible license.

--
Dmitry.

[Mike Hearn]

Sure, but winebuild is a tool - what do we lose if winebuild is GPLd
rather than LGPLd? No proprietary software would need to link against
it, right?

On Fri, 2003-04-11 at 00:23, Dmitry Timoshkov wrote:
> "Mike Hearn" <mike(a)theoretic.com> wrote:
> > Why do we care about the L part of the LGPL for the tools? For the
> > libraries it's clearly important, but for the setup/build tools?
>
> Because libbfd is a library. See the quote below.
> > > "Piotr PawЁow" <pp(a)siedziba.pl> wrote:
> > > > Shouldn't winebuild, however, use libbfd where available,
> > > > instead of relying on nm output?
> > >
> > > AFAIK libbfd is GPL'ed, i.e. has an incompatible license.
>
> --
> Dmitry.

[Dmitry Timoshkov]

"Mike Hearn" <mike(a)theoretic.com> wrote:
> Sure, but winebuild is a tool - what do we lose if winebuild is GPLd
> rather than LGPLd? No proprietary software would need to link against
> it, right?

I see now what you mean by "tools". Having the whole tree under a single
licence saves a bit of hassle, time, hairs, nerves...

-- 
Dmitry.