cgdb-devel — Development activity -- bug reports, patches, related questions

Re: [Cgdb-devel] Re: cgdb 0.5.1 make DESTDIR=... doesn't work

[Robert L. <rob...@se...>]

On Sat, May 21, 2005 at 12:35:11PM -0400, Bob Rossi wrote:
> Is there any chance that you could both try to build CGDB for your
> distro's? I believe I have fixed the problems that you have reported.
> Robert, hopefully you should be able to build CGDB without any patches
> to the autoconf stuff. Benett, hopefully you should be able to do 'make
> DESTDIR=3D... install'.
>=20
> Please let me know as soon as possible. I've found a critical bug in
> CGDB on platforms other than linux and want to put up another minor
> release.

i checked out the current cvs version, and tried a debian build on it.
works like a charm! that's really cool to see. if you are doing a new
version i have two more things to throw in:
- could you update the config.sub and config.guess files to current
  versions? it would make it easier to build under weird systems
  (like GNU/kFreeBSD). you just need to copy over newer files,
  everything from 2005 should be fine
- i wrote a manual page for debian, but it's really bad and should be in
  the upstream source anyway. perhaps you want to have a quick look, fix
  the most stupid mistakes and put it into your cvs

cu  robert =20

--=20
Robert Lemmen                               http://www.semistable.com=20

Re: [Cgdb-devel] Re: cgdb 0.5.1 make DESTDIR=... doesn't work

[Bob R. <bo...@br...>]

On Mon, Apr 04, 2005 at 09:55:14AM +0200, Robert Lemmen wrote:
> On Sun, Apr 03, 2005 at 07:58:59PM -0400, Bob Rossi wrote:
> > I'll make an effort to fix this for 0.5.2. If anyone has any
> > suggestions, please let me know.
>=20
> please do not remove it, debian very much needs it. i don't really know
> how ti fix it properly, but from what i see the problem is that the
> recursive automake install targets in the makefiles depend on wrong
> stuff. i use destdir extensively during the build process with the
> following patch, of course the Makefile.in files are generated, so you
> should rather patch the source file than the resut...

Hi Robert and Bennett,

Is there any chance that you could both try to build CGDB for your
distro's? I believe I have fixed the problems that you have reported.
Robert, hopefully you should be able to build CGDB without any patches
to the autoconf stuff. Benett, hopefully you should be able to do 'make
DESTDIR=3D... install'.

Please let me know as soon as possible. I've found a critical bug in
CGDB on platforms other than linux and want to put up another minor
release.

Thanks,
Bob Rossi

[Cgdb-devel] [ cgdb-Bugs-1189269 ] On FreeBSD 5.2.1 cgdb don't respond on keypress

[SourceForge.net <no...@so...>]

Bugs item #1189269, was opened at 2005-04-25 12:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=534974&aid=1189269&group_id=72581

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pavel S. Shirshov (pchel)
Assigned to: Nobody/Anonymous (nobody)
Summary: On FreeBSD 5.2.1 cgdb don't respond on keypress

Initial Comment:
up

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=534974&aid=1189269&group_id=72581

Re: [Cgdb-devel] Re: cgdb 0.5.1 make DESTDIR=... doesn't work

[Bob R. <bo...@br...>]

On Mon, Apr 04, 2005 at 09:55:14AM +0200, Robert Lemmen wrote:
> On Sun, Apr 03, 2005 at 07:58:59PM -0400, Bob Rossi wrote:
> > I'll make an effort to fix this for 0.5.2. If anyone has any
> > suggestions, please let me know.
>=20
> please do not remove it, debian very much needs it. i don't really know
> how ti fix it properly, but from what i see the problem is that the
> recursive automake install targets in the makefiles depend on wrong
> stuff. i use destdir extensively during the build process with the
> following patch, of course the Makefile.in files are generated, so you
> should rather patch the source file than the resut...

Thanks Robert. I should have clarified. For 0.5.2 I'll try to get the
'make DESTDIR=3D... install' rule working. I'll make sure not to take
anything out.

Thanks for the patch, this will be my starting point. :)

Bob Rossi

Re: [Cgdb-devel] Re: cgdb 0.5.1 make DESTDIR=... doesn't work

[Robert L. <rob...@se...>]

On Sun, Apr 03, 2005 at 07:58:59PM -0400, Bob Rossi wrote:
> I'll make an effort to fix this for 0.5.2. If anyone has any
> suggestions, please let me know.

please do not remove it, debian very much needs it. i don't really know
how ti fix it properly, but from what i see the problem is that the
recursive automake install targets in the makefiles depend on wrong
stuff. i use destdir extensively during the build process with the
following patch, of course the Makefile.in files are generated, so you
should rather patch the source file than the resut...

--- cgdb-0.5.1.orig/various/adt/src/Makefile.in
+++ cgdb-0.5.1/various/adt/src/Makefile.in
@@ -537,7 +537,9 @@
=20
 info-am:
=20
-install-data-am: install-noinst_binPROGRAMS
+# debian workaround
+#install-data-am: install-noinst_binPROGRAMS
+install-data-am:=20
=20
 install-exec-am:
=20
--- cgdb-0.5.1.orig/various/rlctx/src/Makefile.in
+++ cgdb-0.5.1/various/rlctx/src/Makefile.in
@@ -408,7 +408,9 @@
=20
 info-am:
=20
-install-data-am: install-noinst_binPROGRAMS
+# debian workaround
+#install-data-am: install-noinst_binPROGRAMS
+install-data-am:=20
=20
 install-exec-am:
=20
--- cgdb-0.5.1.orig/tgdb/tgdb-base/src/Makefile.in
+++ cgdb-0.5.1/tgdb/tgdb-base/src/Makefile.in
@@ -414,7 +414,9 @@
=20
 info-am:
=20
-install-data-am: install-noinst_binPROGRAMS
+# workaround for debian
+#install-data-am: install-noinst_binPROGRAMS
+install-data-am:=20
=20
 install-exec-am:
=20
--- cgdb-0.5.1.orig/cgdb/tokenizer/src/Makefile.in
+++ cgdb-0.5.1/cgdb/tokenizer/src/Makefile.in
@@ -402,7 +402,9 @@
=20
 info-am:
=20
-install-data-am: install-noinst_binPROGRAMS
+# fix for debian=20
+#install-data-am: install-noinst_binPROGRAMS
+install-data-am:=20
=20
 install-exec-am:
=20
--- cgdb-0.5.1.orig/cgdb/lib/kui/src/Makefile.in
+++ cgdb-0.5.1/cgdb/lib/kui/src/Makefile.in
@@ -406,7 +406,9 @@
=20
 info-am:
=20
-install-data-am: install-noinst_binPROGRAMS
+# dirty fix to work arouind DESTDIR problem
+# install-data-am: install-noinst_binPROGRAMS
+install-data-am:
=20
 install-exec-am:
=20
--- cgdb-0.5.1.orig/cgdb/lib/wm/src/Makefile.in
+++ cgdb-0.5.1/cgdb/lib/wm/src/Makefile.in
@@ -402,7 +402,9 @@
=20
 info-am:
=20
-install-data-am: install-noinst_binPROGRAMS
+# dirty fix to work around debian problem
+#install-data-am: install-noinst_binPROGRAMS
+install-data-am:=20
=20
 install-exec-am:

cu  robert

--=20
Robert Lemmen                               http://www.semistable.com=20

Re: [Cgdb-devel] Re: cgdb 0.5.1 make DESTDIR=... doesn't work

[Bob R. <bo...@br...>]

On Sun, Apr 03, 2005 at 11:13:50PM +0000, Bennett Todd wrote:
> 2005-04-03T22:46:50 Robert Rossi:
> > I've never used DESTDIR before, how is this different than ./configure
> > --prefix=3D/var/tmp/bpmbuild.20581/root ?
>=20
> As a followup, it looks like for cgdb this works:
>=20
> 	./configure --prefix=3D/usr
> 	make
> 	make prefix=3D$BPM_ROOT/usr install
>=20
> That's generally a less-desireable pattern, since with some packages
> the "make install" target causes some rebuilding, and when building
> the prefix can get wired into binaries and config files and the
> like. DESTDIR is better when it works.
>=20
> But if getting DESTDIR working right for cgdb turns out to be
> impractical, then next best would be to simply remove it from the
> Makefiles completely.

I'll make an effort to fix this for 0.5.2. If anyone has any
suggestions, please let me know.

Thanks,
Bob Rossi

[Cgdb-devel] Re: cgdb 0.5.1 make DESTDIR=... doesn't work

[Bennett T. <be...@ra...>]

2005-04-03T22:46:50 Robert Rossi:
> I've never used DESTDIR before, how is this different than ./configure
> --prefix=/var/tmp/bpmbuild.20581/root ?

As a followup, it looks like for cgdb this works:

	./configure --prefix=/usr
	make
	make prefix=$BPM_ROOT/usr install

That's generally a less-desireable pattern, since with some packages
the "make install" target causes some rebuilding, and when building
the prefix can get wired into binaries and config files and the
like. DESTDIR is better when it works.

But if getting DESTDIR working right for cgdb turns out to be
impractical, then next best would be to simply remove it from the
Makefiles completely.

-Bennett

[Cgdb-devel] Re: cgdb 0.5.1 make DESTDIR=... doesn't work

[Bennett T. <be...@ra...>]

2005-04-03T22:46:50 Robert Rossi:
> I've never used DESTDIR before, how is this different than ./configure
> --prefix=/var/tmp/bpmbuild.20581/root ?

When creating a software package, e.g. rpm, or my own bpm, the
typical pattern is

	./configure --prefix=/usr --mandir=/usr/share/man
	make
	make DESTDIR=$BPM_ROOT install

(RPM uses $RPM_ROOT). With that pattern, user executables get
installed into $DESTDIR/usr/bin, man pages in
$DESTDIR/usr/share/man, etc --- DESTDIR is prepended to whatever
dirs were chosen at ./configure time. When creating software
packages, the package-building tool makes an empty tmp dir,
populates it with make DESTDIR=... install, then packs up the files
that got installer there to make the software package.

I hope this explanation is clear.

-Bennett

[Cgdb-devel] Re: cgdb 0.5.1 make DESTDIR=... doesn't work

[Robert R. <bob...@co...>]

On Sun, Apr 03, 2005 at 06:27:21PM +0000, Bennett Todd wrote:
> The DESTDIR target is for overriding the install dest (more
> precisely, prepending some temporary prefix to it) for creating
> software packages.
> 
> You seem to have most of the structure for DESTDIR-relative installs
> in place, but not quite all, when I try one I get an error
> 
> 	make 'DESTDIR=/var/tmp/bpmbuild.20581/root' install
> 	[...]
> 	/bin/bash ../../../../config/mkinstalldirs /var/tmp/bpmbuild.20581/root../../../../progs
> 	mkdir -p -- /var/tmp/bpmbuild.20581/root../../../../progs
> 	cannot create directory `/var/tmp/bpmbuild.20581/root../../../../progs': Permission denied
> 	make[5]: *** [install-noinst_binPROGRAMS] Error 1
> 	make[5]: Leaving directory `/var/tmp/bpmbuild.20581/build/cgdb-0.5.1/cgdb/lib/kui/src'
> 
> Note that the DESTDIR is getting a string of ../../..s appended to
> it, with no slash before, which is wrong twice. Happily, I run make
> install as a non-root user, so this didn't whizz on the root of my
> filesystem.

Ouch, that could be ugly. Thanks for the input.

I've never used DESTDIR before, how is this different than ./configure
--prefix=/var/tmp/bpmbuild.20581/root ?

Anyone have a quick suggestion on how to fix this?

Thanks,
Bob Rossi

Re: [Cgdb-devel] b and f commands in source viewer

[Bob R. <bo...@br...>]

On Fri, Apr 01, 2005 at 08:14:47AM -0500, Ronald Landheer-Cieslak wrote:
> On Mar 31, 2005 11:13 PM, Bob Rossi <bo...@br...> wrote:
> > The README shows that from the source veiw, the below 2 commands can be
> > done.
> >=20
> >    b -> View the previous source file
> >    f -> View the next source file
> >=20
> > I added these a long time ago and now think it was a mistake. Does anyo=
ne
> > object to me taking out these commands and deprecating the feature?
> Nope, but "deprecating" the feature would imply that the commands stay
> there for a while - I think you mean "obsoleting", no?

Yes, you are correct. Unless anyone else objects I will remove this
feature and mark it as obsolete in the NEWS file.

A 0.5.1 is pretty close.

Thanks,
Bob Rossi

Re: [bob@brasko.net: Re: [Cgdb-devel] cgdb on GNU/kFreeBSD]

[Bob R. <bo...@br...>]

On Fri, Apr 01, 2005 at 10:54:13AM -0500, Bob Rossi wrote:
> > i do have a few things (all in debian's cvs):
> > - please update the config.guess and config.sub files to current
> >   versions, this would allow to build your package on may more systems,
> >   including the hurd!
>=20
> OK, I'll look into how to do this, although I have no idea. This is
> what I run to produce all the auto files,
>    rm -rf autom4te.cache/
>=20
>    aclocal -I config
>    autoconf
>    autoheader
>    automake -a
>=20
> I'll look and see if I just need to update either autoconf or something
> ...

Done.
> > - there is the old problem of segfaults on tsartup when ~/.tgdb isn't
> >   writeable. the problem itself isn't really important, but when
> >   investigating it and trying to build a patch i noticed that the error
> >   reporting involved is a bit weird. might be wrong, but you should have
> >   a look when you have time.
>=20
> Yeah, I'm not terribly proud of the code in this application. By the
> time 1.0 hits, most of it will be re-written. I'll look into fixing at
> least this problem.

Is this good enough?

$ ./cgdb/src/cgdb
Error: Could not open file /home/bob/.tgdb/tgdb_log.txt for writing
Error: Could not open log file
Could not initialize logger interface
cgdb.c:662 Unable to invoke GDBbob@black ~/cvs/cgdb/cgdb

> > - and there is a new problem (#296770) that i have to admit i didn't
> >   have the time to look into yet. the reporter says that when you
> >   recompile your program, cgdb doesn't reload the symbols.
>=20
> Yeah, I mean, this has nothing to do with CGDB. GDB is responsible for
> all the symbol loading. However, if the user is saying that CGDB
> displays the old "source code" in the source viewer than that could be a
> problem. I've added 2 new features in this release.
>=20
> Problem is, the interface I have with GDB is not good enough to tell me
> when a source file has been changed (because recompiled). So, I have no
> way of knowing when to fetch the new file, instead of looking at the one
> that was used when CGDB first needed the file.
>=20
> So, I added the :edit [:e] feature, which allows you to reload the
> current file you are looking at.
>=20
> Also, I added the autosourcereload feature, here is the info from the
> README
>=20
>     :set autosourcereload ->=20
>       If this is on, CGDB will automatically reload a
>       source file if it has changed since CGDB has opened it.
>       If it is off, the file will never be reloaded, until you
>       start CGDB again. The default is off.  (:set asr)
>       This feature is useful when you are debugging a program,
>       then you modify a source file, recompile, and 'r' in
>       GDB's CLI window. The file in this case will be updated
>       to show the new version.
>       Note, CGDB only looks at the timestamp of the source file to
>       determine if it has changed. So if you modify the source file,
>       and didn't recompile yet, CGDB will still pick up on the changes.

And will this solve the last problem?

This might be enough to solve all the debian bug reports. Please let me
know.

Bob Rossi

Re: [bob@brasko.net: Re: [Cgdb-devel] cgdb on GNU/kFreeBSD]

[Bob R. <bo...@br...>]

> i do have a few things (all in debian's cvs):
> - please update the config.guess and config.sub files to current
>   versions, this would allow to build your package on may more systems,
>   including the hurd!

OK, I'll look into how to do this, although I have no idea. This is
what I run to produce all the auto files,
   rm -rf autom4te.cache/

   aclocal -I config
   autoconf
   autoheader
   automake -a

I'll look and see if I just need to update either autoconf or something
...

> - there is the old problem of segfaults on tsartup when ~/.tgdb isn't
>   writeable. the problem itself isn't really important, but when
>   investigating it and trying to build a patch i noticed that the error
>   reporting involved is a bit weird. might be wrong, but you should have
>   a look when you have time.

Yeah, I'm not terribly proud of the code in this application. By the
time 1.0 hits, most of it will be re-written. I'll look into fixing at
least this problem.

> - and there is a new problem (#296770) that i have to admit i didn't
>   have the time to look into yet. the reporter says that when you
>   recompile your program, cgdb doesn't reload the symbols.

Yeah, I mean, this has nothing to do with CGDB. GDB is responsible for
all the symbol loading. However, if the user is saying that CGDB
displays the old "source code" in the source viewer than that could be a
problem. I've added 2 new features in this release.

Problem is, the interface I have with GDB is not good enough to tell me
when a source file has been changed (because recompiled). So, I have no
way of knowing when to fetch the new file, instead of looking at the one
that was used when CGDB first needed the file.

So, I added the :edit [:e] feature, which allows you to reload the
current file you are looking at.

Also, I added the autosourcereload feature, here is the info from the
README

    :set autosourcereload -> 
      If this is on, CGDB will automatically reload a
      source file if it has changed since CGDB has opened it.
      If it is off, the file will never be reloaded, until you
      start CGDB again. The default is off.  (:set asr)
      This feature is useful when you are debugging a program,
      then you modify a source file, recompile, and 'r' in
      GDB's CLI window. The file in this case will be updated
      to show the new version.
      Note, CGDB only looks at the timestamp of the source file to
      determine if it has changed. So if you modify the source file,
      and didn't recompile yet, CGDB will still pick up on the changes.


> do you have any plans on when you want to release the next version? i'm
> asking because the sarge freeze is quite imminent now... (for real!)

I'd like to release as soon as possible. There have been many many bug
fixes since the last release, and CGDB should be much more stable for
people.

Thanks,
Bob Rossi

Re: [Cgdb-devel] b and f commands in source viewer

[Ronald Landheer-C. <bly...@gm...>]

On Mar 31, 2005 11:13 PM, Bob Rossi <bo...@br...> wrote:
> The README shows that from the source veiw, the below 2 commands can be
> done.
> 
>    b -> View the previous source file
>    f -> View the next source file
> 
> I added these a long time ago and now think it was a mistake. Does anyone
> object to me taking out these commands and deprecating the feature?
Nope, but "deprecating" the feature would imply that the commands stay
there for a while - I think you mean "obsoleting", no?

rlc

[Cgdb-devel] b and f commands in source viewer

[Bob R. <bo...@br...>]

Hi all,

The README shows that from the source veiw, the below 2 commands can be
done.

   b -> View the previous source file
   f -> View the next source file

I added these a long time ago and now think it was a mistake. Does anyone=
=20
object to me taking out these commands and deprecating the feature?

Thanks,
Bob Rossi

Re: [Cgdb-devel] cgdb on GNU/kFreeBSD

[Bob R. <bo...@br...>]

On Wed, Nov 17, 2004 at 02:14:20PM +0100, Robert Lemmen wrote:
> On Mon, Nov 15, 2004 at 10:37:20AM -0500, Bob Rossi wrote:
> > I recently fixed a compile error for someone on FreeBSD. Do you think
> > this fixed the problem in question? How would I find out?
>=20
> if there is a new release i can ask the guys who reported the bug to try =
it.
> did you also update the config.* files?

Hi Robert,

I am getting ready to do another minor release of CGDB. The release has
several bug fixes that people should have.

Are there any issues you would like me to fix before the release?

Thanks,
Bob Rossi

[Cgdb-devel] [ cgdb-Bugs-1094089 ] Build error on FreeBSD 5.3

[SourceForge.net <no...@so...>]

Bugs item #1094089, was opened at 2005-01-01 15:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=534974&aid=1094089&group_id=72581

Category: CGDB
Group: version 0.5.*
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Norvelle (enorvelle)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build error on FreeBSD 5.3

Initial Comment:
When doing an out-of-the-box build, I get the following
error:

In file included from pseudo.c:49:
/usr/include/libutil.h:72: error: syntax error before
"int64_t"
pseudo.c:105: warning: static declaration of 'strlcpy'
follows non-static declaration
/usr/include/string.h:85: warning: previous declaration
of 'strlcpy' was here
*** Error code 1

Doing a Google for this error, I discover that the
"int64_t" type causes problems on FreeBSD unless the
sys/types.h file is included prior to including util.h. 

So, by moving the #include <sys/types.h> up before
"#ifdef HAVE_UTIL_H", everything works fine.

Thanks!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=534974&aid=1094089&group_id=72581

Re: [Cgdb-devel] cgdb on GNU/kFreeBSD

[Robert L. <rob...@se...>]

On Mon, Nov 15, 2004 at 10:37:20AM -0500, Bob Rossi wrote:
> I recently fixed a compile error for someone on FreeBSD. Do you think
> this fixed the problem in question? How would I find out?

if there is a new release i can ask the guys who reported the bug to try it.
did you also update the config.* files?

cu  robert

--=20
Robert Lemmen                               http://www.semistable.com=20

Re: [Cgdb-devel] cgdb on GNU/kFreeBSD

[Bob R. <bo...@br...>]

On Mon, Nov 15, 2004 at 10:58:57AM +0100, Robert Lemmen wrote:
> hi folks,
>=20
> did you see this [0] "bug"? this probably bites on other BSDs too...
>=20
> cu  robert
>=20
> [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D277346

I recently fixed a compile error for someone on FreeBSD. Do you think
this fixed the problem in question? How would I find out?

Bob Rossi

[Cgdb-devel] cgdb on GNU/kFreeBSD

[Robert L. <rob...@se...>]

hi folks,

did you see this [0] "bug"? this probably bites on other BSDs too...

cu  robert

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D277346

--=20
Robert Lemmen                               http://www.semistable.com=20

[Cgdb-devel] [ cgdb-Bugs-996671 ] Source file reload

[SourceForge.net <no...@so...>]

Bugs item #996671, was opened at 2004-07-23 20:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=534974&aid=996671&group_id=72581

Category: Interface (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marius MUJA (mariusmuja)
Assigned to: Nobody/Anonymous (nobody)
Summary: Source file reload

Initial Comment:
If I change a source file while debugging with cgdb,
recompile and re-run the program in cgdb the source
window does not get refreshed( although I can see the
change with the list gdb command).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=534974&aid=996671&group_id=72581

[Cgdb-devel] [ cgdb-Bugs-996648 ] Source file reload

[SourceForge.net <no...@so...>]

Bugs item #996648, was opened at 2004-07-23 19:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=534974&aid=996648&group_id=72581

Category: Interface (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marius MUJA (mariusmuja)
Assigned to: Nobody/Anonymous (nobody)
Summary: Source file reload

Initial Comment:
If I change a source file while debugging with cgdb,
recompile and re-run the program in cgdb the source
window does not get refreshed( although I can see the
change with the list gdb command).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=534974&aid=996648&group_id=72581

Re: [Cgdb-devel] cgdb 0.4.2 build problem

[Robert L. <rob...@se...>]

On Wed, Jul 14, 2004 at 02:42:47PM -0400, Bob Rossi wrote:
> No, however, I suggest you try checking out a fresh tree and trying
> again. I just did a commit and it might have fixed the problem.
> I also just did a fresh checkout, ./configure && make && make install,
> and the progs directory contains all 10 programs.

sorry, but i can't confirm this. just do an export DESTDIR=3D/tmp before
the make install. and looking at cgdb/lib/kui/src/Makefile (for example)

line 193, in the "install-noinst_binPROGRAMS" target:
    $(mkinstalldirs) $(DESTDIR)$(noinst_bindir)

i think this should nopt use DESTDIR. i don't know how you generate your
Makefile.in, but if you do it with automake or something similar it
might also be a bug there. if it's too much stress then don't worry for
now, i can patch around it.

cu  robert

--=20
Robert Lemmen                               http://www.semistable.com=20

Re: [Cgdb-devel] cgdb 0.4.2 build problem

[Bob R. <bo...@br...>]

On Wed, Jul 14, 2004 at 08:23:34PM +0200, Robert Lemmen wrote:
> On Wed, Jul 14, 2004 at 09:29:20AM -0400, Bob Rossi wrote:
> > OK, I committed the changes to CVS. You can try it out if you'd like. I
> > have a few other quick bug fixes to apply before the next release, but
> > I'll probably get them done today.
>=20
> this looks almost right, but not quite. i build in ~/temp/cgdb and i get
> two progs dirs, one in ~ with kui_driver and wm_drivber in it, and one
> in ~/temp with the following in it:
>=20
> getch_driver  rlctx_driver     std_list_driver  tgdb_driver
> input_driver  std_hash_driver  std_tree_driver  tokenizer_driver
>=20
> both of these dirs should be in ~/temp/cgdb.=20

Yes absolutely. Thanks for finding this problem!

> looking at the makefile, it looks a lot like the old one. actually,
> looking at cvs it's 8 days old. i definitely have an old version. do you
> use the sf.net cvs repo? any tag tricks?

No, however, I suggest you try checking out a fresh tree and trying
again. I just did a commit and it might have fixed the problem.
I also just did a fresh checkout, ./configure && make && make install,
and the progs directory contains all 10 programs.

Thanks,
Bob Rossi

Re: [Cgdb-devel] cgdb 0.4.2 build problem

[Robert L. <rob...@se...>]

On Wed, Jul 14, 2004 at 09:29:20AM -0400, Bob Rossi wrote:
> OK, I committed the changes to CVS. You can try it out if you'd like. I
> have a few other quick bug fixes to apply before the next release, but
> I'll probably get them done today.

this looks almost right, but not quite. i build in ~/temp/cgdb and i get
two progs dirs, one in ~ with kui_driver and wm_drivber in it, and one
in ~/temp with the following in it:

getch_driver  rlctx_driver     std_list_driver  tgdb_driver
input_driver  std_hash_driver  std_tree_driver  tokenizer_driver

both of these dirs should be in ~/temp/cgdb.=20

looking at the makefile, it looks a lot like the old one. actually,
looking at cvs it's 8 days old. i definitely have an old version. do you
use the sf.net cvs repo? any tag tricks?

cu  robert

--=20
Robert Lemmen                               http://www.semistable.com=20

Re: [Cgdb-devel] cgdb 0.4.2 build problem

[Bob R. <bo...@br...>]

On Wed, Jul 14, 2004 at 02:33:31PM +0200, Robert Lemmen wrote:
> On Wed, Jul 14, 2004 at 08:22:41AM -0400, Bob Rossi wrote:
> > OK, sorry to drag this on, so we think DESTDIR has nothing to do with
> > the "progs" directory. Do I have to prefix where CGDB get's installed
> > with it? or does that work fine?
>=20
> right, and the installation otherwise works fine, already uses DESTIDR

OK, cool.

> > So to sum up, we probably don't care about the "progs" directory
> > for binary distributions. So, DESTDIR doesn't matter with the "progs"
> > directory, right? So, you suggest using top_bindir. I wonder if
> > top_builddir is better, because that is guarenteed to be writable. Also,
> > top_builddir will just put the "progs" directory in the build
> > directory. However top_bindir will install it into the installation
> > directory. Is that correct?
> >=20
> > If it is, I would prefer to use top_builddir. If this solves the debian
> > problem, we can release very soon?
>=20
> sorry, my fault. top_builddir is the way to go. if you want to you could
> send me a pre-release tarball and i can try the debian installation
> procedure on it...

OK, I committed the changes to CVS. You can try it out if you'd like. I
have a few other quick bug fixes to apply before the next release, but
I'll probably get them done today.

Bob Rossi