Re: [MinGW-dvlpr] [Mingw-users] Updated: GDB 7.0

[Charles W. <cwi...@us...>]

Chris Sutcliffe wrote:
>> There's a vote for Keith's "reference counting" mingw-get, right there.
>> But that doesn't solve the version clashes -- unless all of
>> gcc|binutils|gdb are released simultaneously, the share/locale/*/*
>> message catalogs will be "wrong" for two of the three packages.
> 
> I *really* need to come up to speed on mingw-get.  Is there a synopsis
> of it's functionality somewhere?

Not really; it's just been discussed at various times on the various
lists. I'm sure the only folks who /really/ know what's what are Keith,
and maybe the TDM guy.

I know that:
  a) it will handle dependendies
  b) package meta data will be encoded in an XML file maintained
     on the mingw site. That xml file may or may not be assembled
     by a script from fragments you and I upload with our packages.
But for more info, Keith will have to chime in.  I recall that in a
message earlier this week he said he was almost ready, maybe, sometime
in the next week or so, to upload his latest development code to CVS for
public comment. But it's still definitely a work in progress.

Originally, Keith had planned that multiple packages could lay claim to
the same file on disk.  Now, assuming that a specific file that falls
into this category is permanently frozen, and always identical, then the
only thing you need to worry about is "reference counting" -- How many
installed packages "reference" that file; don't delete it unless ALL of
those packages are uninstalled (e.g. the reference count goes to zero).
When installing, don't overwrite it if it already exists, but just
increment the reference count.

This doesn't address the version incompatibility problem, where the
various packages that reference a given file intrinsically make
different assumptions about the version.  That is, this
libopcodes.a-2009{10,11,12}01 problem.

Several months ago, I was arguing against the "reference counting"
approach.  I felt it overly complicated the system -- and besides, the
linux distros don't do this, so why should we?  I said that files on
disk should always be owned by exactly one package. This is the way all
of the linux distros I know about handle it: however, they also add
"conflicts" specifications to the metadata, so that 2 or more packages
might own a given file but the metadata and installer work together to
ensure that either one or the other is installed, never both.

Cygwin does it this way, too: but its installer doesn't have conflicts
support, so we have to exercise more control over the packages as they
go into the distro, to manually police for conflicts and fix 'em.

I /thought/ that Keith said he'd be okay going along with that policy,
at least for now in the absence of any /actual/ mingw-get. No sense in
creating a bunch of packages that intrinsically rely on a feature (ref
counting) that may or may not show up in the, at this point, vaporware
future installer.

Anyway, the "one package per file" rule requires a somewhat stronger
central coordination than is, perhaps, desirable in the mingw project.
(I can't believe I'm referring to cygwin as having "strong central
coordination"...)

>> Or you release the opcodes/bfd libraries separately as their "own"
>> packages, and then link gcc|binutils|gdb against them (that's the way
>> mandriva does it).
> 
> That seems to be a logical approach, but wouldn't opcodes / bfd need
> to be updated with each new release of gcc|binutils|gdb to capture the
> latest message catalogs?

Not really -- if you built gcc|binutils|gdb to link against the external
(that is, possible older!) libbfd/libopcodes.  I don't even know if that
is possible.

>  Wouldn't this potentially cause an issue for
> a previous gcc|binutils|gdb if it was linked against one version of
> opcodes/bfd and opcodes/bfd was subsequently updated?

Hence shared libraries, and linking against the installed version. When
the DLLs get updated, so do the catalogs.  Unfortunately, it's very
difficult to convince libopcodes & friends to build shared on win32 --
mostly because they all use libiberty, which nobody builds shared on any
platform. Yet, we wouldn't want to export the libiberty symbols from
opcodes.dll nor from bfd.dll, 'cause they'd clash (never mind that
libtool at least will complain if you try to create a DLL with a static
dependency like that).

Once upon a time I made this kinda work -- but it took a lot of ugly goo
where I unpacked the libiberty into its component .o's, and then linked
the libopcodes and libbfd dlls. I also had to use hand-rolled .def
files, to ensure that none of the libiberty symbols were exported
(maintainance nightmare).  Finally, if you do this, you CAN'T distribute
the libbfd.a and libopcodes.a, because both will contain all the symbols
from libiberty...

> The other concern I have, is that all these plethora of packages with
> no way of maintaining dependencies in an installer will be a nightmare
> for MinGW users to sort out. 

For now, we need to create a wiki page and say "here's the list of stuff
you need".

> Does mingw-get support this type of
> functionality (similar to Cygwin's installer)?

AFAIK, yes it will.

--
Chuck