Re: [Mingw-users] Updated: GDB 7.0

[Chris Sutcliffe-2]

I've taken this to the developer list...

>> My guess is that these files should be distributed by binutils, not gdb.
>
> 'Course, I've never really understood how, when you have i18n'ized
> libraries like bfd and opcodes, who "owns" the message catalogs in
> share/locale/.
>
> I mean, I build gcc (which links in a static copy of libopcodes/libbfd)
> using 20091001.
>
> Then you build gdb (which links another static copy of
> libopcodes/libbfd) using 20091101.
>
> Then somebody else builds binutils (which links yet a third copy of
> those libs) using 20091201.  Presumably, "binutils" owns the libraries,
> so it gets to install lib/libopcodes* -- and share/locale/*/opcodes.mo?
>
> But that means that gcc and gdb don't get to install the message
> catalogs for their in-built libopcodes.  Or, if they did, then binutils
> just clobbered them with a version that is two months newer.

It's an on going issue for sure...

> 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?

> 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?  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?

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.  Does mingw-get support this type of
functionality (similar to Cygwin's installer)?

Chris

--
Chris Sutcliffe
http://emergedesktop.org

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Charles Wilson-8]

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[siva221]

Hello.

I cross-compiled Insight 6.8-1 on windows using minGW.

When I run the application by plane gdb in console mode, 100% of gdb
works and when I press Ctrl-C (while the application is in while(1)
loop) gdp stops saying "Program received signal SIGINT, Interrupt.".


Click 'Run' then 'Continue', then while code is executing, click 'Stop'.
The X session appears to die immediately, and you're dumped back into gdm or whatever.

When I try to do the same in Insight, it hangs. I can not press any
button (including interrupt) or enter any menu item. Only kill command
helps.