RE: trying to build gdb with renamed cygwin1.dll

RE: trying to build gdb with renamed cygwin1.dll

[Fahd Abidi]

Actually I am planning on eventually building a cross debugger for
arm/ppc/mips/xscale. But that will be afterwards. Right now I am just
trying to get the gdb binary to be stand alone. Actually I had allot of
success with building with the --disable-shared and --enable-static
option and was able to move the resulting gdb across different versions
of cygwin1.dll without it complain about using an incompatible version
of cygwin1.dll.

I think I will use this and play some games with a batch script and
figure out how to detect an existing version of cygwin1.dll then use
that info to decide whether to install my own version before gdb starts
up. Sounds like that will be the easiest solution.

Thanks for all the help. Sorry if I posted your email will be more
careful in the future. Is there a moderator here that can remove the
email address from my previous post?

thanks,

Fahd
 

-----Original Message-----
From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
Behalf Of Andrew STUBBS
Sent: Monday, April 30, 2007 12:30 PM
To: gdb@sourceware.org
Cc: Fahd Abidi
Subject: Re: trying to build gdb with renamed cygwin1.dll

Brian Dessent wrote:
> I think the two of you are talking about two different things.  It 
> sounds like he's trying to build a native debugger, and you're talking

> about a MinGW-hosted cross.  As far as I know (and I could be wrong), 
> building a native MinGW gdb does not work currently and hasn't for 
> some years, because it requires a ton of local patches that were never

> contributed.  The MinGW site indeed offers only a circa-2003 gdb v6.0 
> and a 2005 vintage v6.3, and that's it.

Fair point, I am talking about my experience with a cross-debugger.

He doesn't actually say what his debugger targets, but I had assumed it
was not native because, if he has Cygwin, he already has a native GDB.

Sorry if I've confused the matter.

Andrew

Re: trying to build gdb with renamed cygwin1.dll

[Andrew STUBBS]

Fahd Abidi wrote:
> Actually I am planning on eventually building a cross debugger for
> arm/ppc/mips/xscale. But that will be afterwards. Right now I am just
> trying to get the gdb binary to be stand alone. Actually I had allot of
> success with building with the --disable-shared and --enable-static
> option and was able to move the resulting gdb across different versions
> of cygwin1.dll without it complain about using an incompatible version
> of cygwin1.dll.

Well, if you intend to use a cross-debugger eventually, it's probably 
best to start out with one now. They don't need as much support for the 
host as a native debugger, and so are more likely to build. In the case 
of MinGW, this is particularly true.

If the debugger does not yet support your target then just pick a random 
  target and pipe-clean your build with that. Some have issues of their 
own, but most work.

> Thanks for all the help. Sorry if I posted your email will be more
> careful in the future. Is there a moderator here that can remove the
> email address from my previous post?

No, once it's in the wild it's not retrievable.

See this absolutely hilarious attempt to get a message removed from the 
GCC archive:
http://gcc.gnu.org/ml/gcc-help/2006-06/msg00205.html
http://gcc.gnu.org/ml/gcc-help/2006-06/msg00208.html
http://gcc.gnu.org/ml/gcc-help/2006-06/msg00211.html
http://gcc.gnu.org/ml/gcc-help/2006-06/msg00215.html
(sorry for multiple links - they're not very well threaded).

Andrew

RE: trying to build gdb with renamed cygwin1.dll

[Dave Korn]

On 30 April 2007 17:42, Fahd Abidi wrote:

> Actually I am planning on eventually building a cross debugger for
> arm/ppc/mips/xscale. But that will be afterwards. Right now I am just
> trying to get the gdb binary to be stand alone. Actually I had allot of
> success with building with the --disable-shared and --enable-static
> option and was able to move the resulting gdb across different versions
> of cygwin1.dll without it complain about using an incompatible version
> of cygwin1.dll.

  You're putting an awful lot of effort into a mostly-imaginary problem.
Cygwin1.dll attempts to remain backwardly-compatible.  The last ABI break I
was remember was something to do with the __reent_impure pointer and it
happened sometime back around 1.5.3 IIRC.

  The one thing you can't do is carry around a copy of the cygwin dll that you
compiled against, and put gdb and that dll onto a system that already has a
different version of the dll installed; they will clash.

  But you shouldn't need to do that anyway; if there's an exisiting cygwin
install, you just need to copy gdb.exe across.  Apart from the occasional
break, as I mentioned above, /most/ versions of gdb compiled agsinst /most/
versions of the dll should work fine against /most/ other versions of the dll.
This is pretty much regardless of --disable-shared and --enable-static,
although if you compiled gdb against a very old or very new cygwin and the one
you're running it on doesn't have some of the same versions of the support
dlls you might find it's missing something, e.g. cygintl-1 vs. cygintl-2.
However, there's no compatibility problems between the differently-numbered
versions of the support dlls, so you should be able to carry a set of those
around and just leave out cygwin1.dll and get what you want.

  Give it a try if you haven't yet.  If you have, plese post the /exact/ error
message, so we can be clear precisely what situation you're talking about.



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: trying to build gdb with renamed cygwin1.dll

[Daniel Jacobowitz]

On Mon, Apr 30, 2007 at 09:11:57PM +0100, Dave Korn wrote:
>   Give it a try if you haven't yet.  If you have, plese post the /exact/ error
> message, [...]

... to the Cygwin mailing list, please.

-- 
Daniel Jacobowitz
CodeSourcery

RE: trying to build gdb with renamed cygwin1.dll

[Fahd Abidi]

I tried the -mno-cygwin option but got several compile errors. I didn't
want to debug the sources because of time constraints. That is why I
thought that compiling against a renamed cygwin1.dll might be an eaisier
solution.

Fahd
 

-----Original Message-----
From: Andrew STUBBS [mailto:andrew.stubbs@st.com] 
Sent: Monday, April 30, 2007 11:30 AM
To: Fahd Abidi
Cc: gdb@sourceware.org
Subject: Re: trying to build gdb with renamed cygwin1.dll

Fahd Abidi wrote:
> My purpose is to try and build a gdb that so I can move it across 
> different windows platforms with out worrying about newer or older 
> versions of the cygwin dll interfering. I already looked at the MinGW 
> option but the newer versions of gdb do not build against mingw32.

I don't know about the exact solution you had in mind, but ....

You might want to investigate the -mno-cygwin GCC option. This builds
"MinGW" binaries (Minimum GNU for Windows) which do not depend upon
anything not present in a standard Windows installation. This is how our
Windows tools are built.

Obviously there are issues with doing it this way - no automatic support
for Cygwin pathnames being the biggest - but most of these can be
overcome with little effort, and all overcome with more effort.

Andrew

Re: trying to build gdb with renamed cygwin1.dll

[Andrew STUBBS]

Fahd Abidi wrote:
> I tried the -mno-cygwin option but got several compile errors. I didn't
> want to debug the sources because of time constraints. That is why I
> thought that compiling against a renamed cygwin1.dll might be an eaisier
> solution.

Well, it was never going to be easy! You might want to check out 
mingw.org but I thought GDB was supposed to Just Work these days.

I did have some problems with it autodetecting cygwin ncurses, which 
obviously isn't going to work, but that can be fixed with 
--disable-readline ... probably. You can get readline to work with 
pdcurses, but that required a little effort.

BTW, you just posted my email address, non-obfuscated, to number of 
web-archives. I'd rather you didn't do that. It would probably be best 
if you stopped your mailer doing that before you fully spam-enable 
everybody else.

Andrew

Re: trying to build gdb with renamed cygwin1.dll

[Brian Dessent]

Andrew STUBBS wrote:

> Well, it was never going to be easy! You might want to check out
> mingw.org but I thought GDB was supposed to Just Work these days.

I think the two of you are talking about two different things.  It
sounds like he's trying to build a native debugger, and you're talking
about a MinGW-hosted cross.  As far as I know (and I could be wrong),
building a native MinGW gdb does not work currently and hasn't for some
years, because it requires a ton of local patches that were never
contributed.  The MinGW site indeed offers only a circa-2003 gdb v6.0
and a 2005 vintage v6.3, and that's it.

Brian

Re: trying to build gdb with renamed cygwin1.dll

[Andrew STUBBS]

Brian Dessent wrote:
> I think the two of you are talking about two different things.  It
> sounds like he's trying to build a native debugger, and you're talking
> about a MinGW-hosted cross.  As far as I know (and I could be wrong),
> building a native MinGW gdb does not work currently and hasn't for some
> years, because it requires a ton of local patches that were never
> contributed.  The MinGW site indeed offers only a circa-2003 gdb v6.0
> and a 2005 vintage v6.3, and that's it.

Fair point, I am talking about my experience with a cross-debugger.

He doesn't actually say what his debugger targets, but I had assumed it 
was not native because, if he has Cygwin, he already has a native GDB.

Sorry if I've confused the matter.

Andrew

trying to build gdb with renamed cygwin1.dll

[Fahd Abidi]

Hello,

I was trying to build a gdb version that would use a renamed version of
cygwin1.dll and some of the other dll's that gdb seem to depend on. I
determined all the dll's that gdb relies on using the "cygcheck" command

My purpose is to try and build a gdb that so I can move it across
different windows platforms with out worrying about newer or older
versions of the cygwin dll interfering. I already looked at the MinGW
option but the newer versions of gdb do not build against mingw32.

My procedure was something like so, copied and renamed the dll's
cygwin1, cygiconv-2,cygitl-3,cygcurses-8,tcl84,tk84 into another
directory. Then tried to compile gdb against these renamed dll's by
using the --libdir configure option. Unfortunately the resulting gdb
executable totally ignores these renamed libraries and still links
against the original dlls.

Is this going to be possible to do?

Thanks allot in advance.

Fahd
 

Re: trying to build gdb with renamed cygwin1.dll

[Bob Rossi]

On Mon, Apr 30, 2007 at 11:09:12AM -0400, Fahd Abidi wrote:
> Hello,
> 
> I was trying to build a gdb version that would use a renamed version of
> cygwin1.dll and some of the other dll's that gdb seem to depend on. I
> determined all the dll's that gdb relies on using the "cygcheck" command
> 
> My purpose is to try and build a gdb that so I can move it across
> different windows platforms with out worrying about newer or older
> versions of the cygwin dll interfering. I already looked at the MinGW
> option but the newer versions of gdb do not build against mingw32.

IMO, this is a really bad idea. The cygwin1.dll uses shared memory 
at a fixed location. So, renaming the dll won't help. You will still 
get the same old errors.

> My procedure was something like so, copied and renamed the dll's
> cygwin1, cygiconv-2,cygitl-3,cygcurses-8,tcl84,tk84 into another
> directory. Then tried to compile gdb against these renamed dll's by
> using the --libdir configure option. Unfortunately the resulting gdb
> executable totally ignores these renamed libraries and still links
> against the original dlls.
> 
> Is this going to be possible to do?

No, don't do it. Stop where you are.

Bob Rossi

Re: trying to build gdb with renamed cygwin1.dll

[Bob Rossi]

On Mon, Apr 30, 2007 at 11:09:56AM -0400, Bob Rossi wrote:
> On Mon, Apr 30, 2007 at 11:09:12AM -0400, Fahd Abidi wrote:
> > Hello,
> > 
> > I was trying to build a gdb version that would use a renamed version of
> > cygwin1.dll and some of the other dll's that gdb seem to depend on. I
> > determined all the dll's that gdb relies on using the "cygcheck" command
> > 
> > My purpose is to try and build a gdb that so I can move it across
> > different windows platforms with out worrying about newer or older
> > versions of the cygwin dll interfering. I already looked at the MinGW
> > option but the newer versions of gdb do not build against mingw32.
> 
> IMO, this is a really bad idea. The cygwin1.dll uses shared memory 
> at a fixed location. So, renaming the dll won't help. You will still 
> get the same old errors.

Here's a little proof,

  http://www.cygwin.com/ml/cygwin/2005-03/msg00699.html

Bob Rossi

Re: trying to build gdb with renamed cygwin1.dll

[Andrew STUBBS]

Fahd Abidi wrote:
> My purpose is to try and build a gdb that so I can move it across
> different windows platforms with out worrying about newer or older
> versions of the cygwin dll interfering. I already looked at the MinGW
> option but the newer versions of gdb do not build against mingw32.

I don't know about the exact solution you had in mind, but ....

You might want to investigate the -mno-cygwin GCC option. This builds 
"MinGW" binaries (Minimum GNU for Windows) which do not depend upon 
anything not present in a standard Windows installation. This is how our 
Windows tools are built.

Obviously there are issues with doing it this way - no automatic support 
for Cygwin pathnames being the biggest - but most of these can be 
overcome with little effort, and all overcome with more effort.

Andrew

Re: trying to build gdb with renamed cygwin1.dll

[Brian Dessent]

Fahd Abidi wrote:

> I was trying to build a gdb version that would use a renamed version of
> cygwin1.dll and some of the other dll's that gdb seem to depend on. I
>
> [...]
> 
> Is this going to be possible to do?

Short answer, it's not going to be possible without a lot more work than
what you've done.  Unfortunately, Cygwin is complicated, and it jumps
through a ton of hoops to get that magical POSIX emulation under Win32.

Since this is the gdb list it's not particularly topical, so I will try
to be brief.  I'm sure gdb developers don't really care about this much
so please take any replies to the Cygwin list.

For one thing, as Bob already mentioned, Cygwin uses a shared memory
region for interprocess communication between other Cygwin processes to
coordinate signals and child/parent communications and so forth.  The
name of this shared memory region must be changed in order to actually
isolate two Cygwin DLLs.  While you're at it you'd also have to change
the registry key used for the mount table, otherwise both Cygwins will
share the same notions of posix-win32 path mappings.  And there is also
a "magic prefix" used to differentiate Cygwin strace messages from other
OutputDebugString() output that you would have to also change so that
two Cygwins would not collide when using strace or gdb.

Further, linking against the Cygwin DLL requires use of an import
library (due to symbol name aliases), and when using an import library
to link the name of the DLL is embedded into the import library.  This
is convenient because it allows for easy library versioning, i.e. you
have an import library libfoo.dll.a that internally references
cygfoo-<some version number>.dll.  Thus you can still link with just
-lfoo but this will pick up the most recent version of the library where
multiple ones exist.  It's directly analogous to making the symlink
libfoo.so -> libfoo-<version>.so on ELF systems.

And the Cygwin DLL is just one; all of the other libs you are using all
have their own import libraries, so they would all need to be rebuilt
with a different DLL name too.  (Hardly anything in the Cygwin distro
makes use of the "direct to DLL linking without import library" feature
of ld, you will find.)  You will end up doing a "make world", patching
and recompiling just about every single library.  Don't forget that gcc
has a -lcygwin in its specs file, so you will need to patch that too.

Finally, there are places in the Cygwin source and build machinery that
assume the DLL is named "cygwin<n>.dll", so if you change this (and
especially if you change it to something of a different length) you will
likely have to patch these places too.

Brian