Re: debugging guile test failure and segfault.

Re: debugging guile test failure and segfault.

[dsmich]

---- "Ludovic Courtès" <ludovic.courtes@laas.fr> wrote: 
> Hi,
> 
> Greg Troxel <gdt@ir.bbn.com> writes:
> 
> > I have this patch lying around from adding pkgconfig support long ago; I
> > think I sent it and there wasn't much interest then.
> 
> FWIW, I'm all in favor of applying such a patch.  We could keep
> `guile-config' for compatibility and have it invoke `pkg-config'
> appropriately.

And keep the old behavior if pkgconfig isn't installed?

-Dale



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Ludovic Courtès]

Hey,

<dsmich@adelphia.net> writes:

> And keep the old behavior if pkgconfig isn't installed?

I did not have that in mind, but why not: `guile-config' is a Guile
script and it's sufficiently flexible for this I suppose.

Thanks,
Ludo'.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

debugging guile test failure and segfault.

[Dan McMahill]

Hello,

I've managed to get guile-1.8.1 to build (with a few patches) on my 
NetBSD/alpha system.  Now I'm trying to investigate some failing tests. 
  The tests which fail are:

Running numbers.test
FAIL: numbers.test: max: big / real: (= big*5 (max big*5 -inf.0))
FAIL: numbers.test: max: real / big: (= big*5 (max -inf.0 big*5))
FAIL: numbers.test: min: big / real: (= big*5 (min big*5 +inf.0))
FAIL: numbers.test: min: real / big: (= big*5 (min +inf.0 big*5))

and then later:


Running r4rs.test
[1]   Segmentation fault      ${dir}${tst}
FAIL: check-guile

The others all pass which I guess is a good sign.

At this point, I have two questions.

1)  Is there a more or less simple way to step through the tests in an 
interactive mode where I can get to the failures in numbers.test to 
really see what values are involved and causing the failure?   I'm 
guessing that either I'm seeing an artifact of alphas being 64-bit 
systems or that alphas may deal differently with IEEE math and things 
like Inf and NaN.

2)  Is there a simple way to get the r4rs.test to run in the debugger so 
I can either track this down myself or provide some more useful feedback?

I'm also working on getting this going on Solaris-2.9/sparc but am not 
quite to the testsuite part.  I have a few bug fix patches there too. 
Once I get my various problems worked out, I'll submit a more cleaned up 
set of patches.

Thanks
-Dan


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Ludovic Courtès]

Hi,

Dan McMahill <mcmahill@mtl.mit.edu> writes:

> Running numbers.test
> FAIL: numbers.test: max: big / real: (= big*5 (max big*5 -inf.0))
> FAIL: numbers.test: max: real / big: (= big*5 (max -inf.0 big*5))
> FAIL: numbers.test: min: big / real: (= big*5 (min big*5 +inf.0))
> FAIL: numbers.test: min: real / big: (= big*5 (min +inf.0 big*5))

These tests should be using `eqv?' rather than `='.  This was fixed on
2006-12-02 (and will appear in the next release).  So, that's nothing to
worry about.

> Running r4rs.test
> [1]   Segmentation fault      ${dir}${tst}
> FAIL: check-guile

I guess you'll have to send us a stack trace.  :-)  So you need to make
sure you compile Guile with the `-g' flags (e.g., by running "make
CFLAGS=-g"); then you can run "gdb libguile/.libs/lt-guile core",
assuming a `core' file was generated when it segfaulted.

> 1)  Is there a more or less simple way to step through the tests in an
> interactive mode where I can get to the failures in numbers.test to
> really see what values are involved and causing the failure?

>From the top-level build directory, you can run:

  $ ./pre-inst-guile test-suite/tests/numbers.test

But for `r4rs.test', you'll need something more complicated:

  $ ./pre-inst-guile -c "
     (module-set! (resolve-module '(test-suite guile-test))
                  'test-suite \"$PWD/test-suite/tests\")
     (module-set! (resolve-module '(test-suite guile-test))
                  'tmp-dir \"/tmp\")
     (load \"test-suite/tests/r4rs.test\")"

(This could surely be improved...)

> 2)  Is there a simple way to get the r4rs.test to run in the debugger
> so I can either track this down myself or provide some more useful
> feedback?

See above: run the debugger on the `core' file.

> I'm also working on getting this going on Solaris-2.9/sparc but am not
> quite to the testsuite part.  I have a few bug fix patches there
> too. Once I get my various problems worked out, I'll submit a more
> cleaned up set of patches.

Nice!

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Dan McMahill]

Ludovic Courtès wrote:
> Hi,
> 
> Dan McMahill <mcmahill@mtl.mit.edu> writes:
> 


>> Running r4rs.test
>> [1]   Segmentation fault      ${dir}${tst}
>> FAIL: check-guile
> 
> I guess you'll have to send us a stack trace.  :-)  So you need to make
> sure you compile Guile with the `-g' flags (e.g., by running "make
> CFLAGS=-g"); then you can run "gdb libguile/.libs/lt-guile core",
> assuming a `core' file was generated when it segfaulted.

ok, I turned off -O2 to avoid any compiler strange behaviour, got the 
core file and ran

gdb libguile/.libs/guile guile.core

a back trace showed that around line 834 of libguile/posix.c there is a 
call to ttyname() which is returning NULL.   Unfortunately that NULL 
pointer is used a few lines later by some functions which try to run 
strlen() on it.  Thats where the segfault is.

I tried configuring with --without-threads to see if turning off 
threading support made a difference and it didn't.

I also added a call to isatty(fd) in there to see it returns true and it 
does so I don't know whats up.  Perhaps there is some other bug on my 
system.  Either way, there should probably be some better error checking 
in posix.c.  There is some error checking but not until after "result" 
is used.

The error is "No such file or directory".  I wonder if perhaps this is 
related to running in a chroot environment.

--- libguile/posix.c.orig       2006-10-04 03:35:07.000000000 +0000
+++ libguile/posix.c
@@ -831,14 +831,20 @@ SCM_DEFINE (scm_ttyname, "ttyname", 1, 0
    scm_i_scm_pthread_mutex_lock (&scm_i_misc_mutex);
    SCM_SYSCALL (result = ttyname (fd));
    err = errno;
-  ret = scm_from_locale_string (result);
-  scm_i_pthread_mutex_unlock (&scm_i_misc_mutex);

    if (!result)
      {
        errno = err;
        SCM_SYSERROR;
+      ret = scm_from_locale_string ("unknown");
+    }
+  else
+    {
+      ret = scm_from_locale_string (result);
      }
+
+  scm_i_pthread_mutex_unlock (&scm_i_misc_mutex);
+
    return ret;
  }
  #undef FUNC_NAME


with this patch instead of a segfault I get:

Running r4rs.test
ERROR: In procedure ttyname:
ERROR: No such file or directory

unfortunately the testsuite still stops running so I don't know what all 
else may still be failing.  After moving aside r4rs.test I make it to:

Running regexp.test
Segmentation fault (core dumped)


#0  0x00000001600d6bb4 in scm_is_pair (x=0x10001202cbd60) at inline.h:272
#1  0x0000000160086434 in scm_sloppy_assq (key=0x1200673a0, 
alist=0x10001202cbd60) at alist.c:53
#2  0x00000001600d2a58 in scm_hash_fn_get_handle (table=0x120321ac0, 
obj=0x1200673a0, hash_fn=0x1600d15ec <scm_ihashq>,
     assoc_fn=0x160086408 <scm_sloppy_assq>, closure=0x0) at hashtab.c:428
#3  0x00000001600d2e20 in scm_hash_fn_ref (table=0x12009aba0, 
obj=0x1200673a0, dflt=0x4, hash_fn=0x1600d15ec <scm_ihashq>,
     assoc_fn=0x160086408 <scm_sloppy_assq>, closure=0x0) at hashtab.c:500
#4  0x00000001600d3304 in scm_hashq_ref (table=0x12009aba0, 
key=0x1200673a0, dflt=0x4) at hashtab.c:613
#5  0x00000001600dc904 in module_variable (module=0x12009ab40, 
sym=0x1200673a0) at modules.c:289
#6  0x00000001600dcabc in scm_eval_closure_lookup (eclo=0x1200f56d0, 
sym=0x1200673a0, definep=0x4) at modules.c:337
#7  0x00000001600dcf38 in scm_sym2var (sym=0x1200673a0, 
proc=0x1200f56d0, definep=0x4) at modules.c:461
#8  0x00000001600a2d6c in scm_lookupcar1 (vloc=0x12071b1e0, 
genv=0x120228620, check=1) at eval.c:2861
#9  0x00000001600a73b0 in ceval (x=0x12071b1e0, env=0x120228620) at 
eval.c:4027
#10 0x00000001600a4d54 in ceval (x=0x1202286d0, env=0x120228620) at 
eval.c:3557
#11 0x00000001600a3cb4 in ceval (x=0x12071adc0, env=0x12071aa10) at 
eval.c:3384
#12 0x00000001600aa168 in scm_apply (proc=0x1201522c0, arg1=0x404, 
args=0x12071aa30) at eval.c:4997
#13 0x00000001600a90b0 in scm_call_0 (proc=0x12071aaa0) at eval.c:4651


After moving aside regexp.test the remaining tests finish with:

Totals for this test run:
passes:                 10091
failures:               1
unexpected passes:      0
expected failures:      25
unresolved test cases:  12
untested test cases:    0
unsupported test cases: 17
errors:                 0

-Dan


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Ludovic Courtès]

Hi,

Dan McMahill <mcmahill@mtl.mit.edu> writes:

> a back trace showed that around line 834 of libguile/posix.c there is
> a call to ttyname() which is returning NULL.   Unfortunately that NULL
> pointer is used a few lines later by some functions which try to run
> strlen() on it.  Thats where the segfault is.

Good catch!  I committed a patch similar to yours along with a test case
in CVS.

> Running r4rs.test
> ERROR: In procedure ttyname:
> ERROR: No such file or directory

I can't see what's causing this in `r4rs.test'.  Could you try running
that test from the prompt and enter the debugger when the error is
raised so that we get a Scheme stack trace?  Roughly:

  $ ./pre-inst-guile
  guile> (module-set! (resolve-module '(test-suite guile-test))
                     'test-suite \"$PWD/test-suite/tests\")
  guile> (module-set! (resolve-module '(test-suite guile-test))
                      'tmp-dir "/tmp\)
  guile> (load "test-suite/tests/r4rs.test")
  [...]
  ERROR: ...
  guile> (debug)
  debug> bt

> Running regexp.test
> Segmentation fault (core dumped)
>
>
> #0  0x00000001600d6bb4 in scm_is_pair (x=0x10001202cbd60) at inline.h:272
> #1  0x0000000160086434 in scm_sloppy_assq (key=0x1200673a0,
> alist=0x10001202cbd60) at alist.c:53
> #2  0x00000001600d2a58 in scm_hash_fn_get_handle (table=0x120321ac0,
> obj=0x1200673a0, hash_fn=0x1600d15ec <scm_ihashq>,
>     assoc_fn=0x160086408 <scm_sloppy_assq>, closure=0x0) at hashtab.c:428
> #3  0x00000001600d2e20 in scm_hash_fn_ref (table=0x12009aba0,
> obj=0x1200673a0, dflt=0x4, hash_fn=0x1600d15ec <scm_ihashq>,
>     assoc_fn=0x160086408 <scm_sloppy_assq>, closure=0x0) at hashtab.c:500
> #4  0x00000001600d3304 in scm_hashq_ref (table=0x12009aba0,
> key=0x1200673a0, dflt=0x4) at hashtab.c:613
> #5  0x00000001600dc904 in module_variable (module=0x12009ab40,
> sym=0x1200673a0) at modules.c:289
> #6  0x00000001600dcabc in scm_eval_closure_lookup (eclo=0x1200f56d0,
> sym=0x1200673a0, definep=0x4) at modules.c:337
> #7  0x00000001600dcf38 in scm_sym2var (sym=0x1200673a0,
> proc=0x1200f56d0, definep=0x4) at modules.c:461
> #8  0x00000001600a2d6c in scm_lookupcar1 (vloc=0x12071b1e0,
> genv=0x120228620, check=1) at eval.c:2861
> #9  0x00000001600a73b0 in ceval (x=0x12071b1e0, env=0x120228620) at
> eval.c:4027
> #10 0x00000001600a4d54 in ceval (x=0x1202286d0, env=0x120228620) at
> eval.c:3557
> #11 0x00000001600a3cb4 in ceval (x=0x12071adc0, env=0x12071aa10) at
> eval.c:3384
> #12 0x00000001600aa168 in scm_apply (proc=0x1201522c0, arg1=0x404,
> args=0x12071aa30) at eval.c:4997
> #13 0x00000001600a90b0 in scm_call_0 (proc=0x12071aaa0) at eval.c:4651

This one is certainly trickier.  The stack trace above is that of a
variable lookup (i.e., not related to regexps).  Can you try running
`regexp.test' alone just to make sure?

Address X is 8-byte aligned, which corresponds to a non-immediate.
Could you try printing (from the debugger) `* ((SCM *) x)' and
`* ((SCM *) x + 1)'?

I'm afraid it'll be quite hard to find out what's going wrong...

Thanks for debugging!

Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Dan McMahill]

Ludovic Courtès wrote:
> Hi,
> 
> Dan McMahill <mcmahill@mtl.mit.edu> writes:
> 
>> a back trace showed that around line 834 of libguile/posix.c there is
>> a call to ttyname() which is returning NULL.   Unfortunately that NULL
>> pointer is used a few lines later by some functions which try to run
>> strlen() on it.  Thats where the segfault is.
> 
> Good catch!  I committed a patch similar to yours along with a test case
> in CVS.
> 
>> Running r4rs.test
>> ERROR: In procedure ttyname:
>> ERROR: No such file or directory
> 
> I can't see what's causing this in `r4rs.test'.  Could you try running
> that test from the prompt and enter the debugger when the error is
> raised so that we get a Scheme stack trace?  Roughly:
> 
>   $ ./pre-inst-guile
>   guile> (module-set! (resolve-module '(test-suite guile-test))
>                      'test-suite \"$PWD/test-suite/tests\")
>   guile> (module-set! (resolve-module '(test-suite guile-test))
>                       'tmp-dir "/tmp\)
>   guile> (load "test-suite/tests/r4rs.test")
>   [...]
>   ERROR: ...
>   guile> (debug)
>   debug> bt
> 
>> Running regexp.test
>> Segmentation fault (core dumped)

# ./pre-inst-guile
guile> (module-set! (resolve-module '(test-suite guile-test))
'test-suite "$PWD/test-suite/tests")
guile> (module-set! (resolve-module '(test-suite guile-test)) 'tmp-dir
"/tmp")
guile> (load "test-suite/tests/r4rs.test")

[snip]
PASS: (6 9): (#<procedure list-length (obj)> (a b . c))
PASS: (6 9): (#<primitive-generic map> #<primitive-procedure cadr> ())

Backtrace:
In unknown file:
    ?: 0* [primitive-load "test-suite/tests/r4rs.test"]
In test-suite/tests/r4rs.test:
  923: 1*
Exception during displaying of backtrace: system-error

test-suite/tests/r4rs.test:88:45: In procedure ttyname in expression
(write (cons fun args) port):
test-suite/tests/r4rs.test:88:45: No such file or directory
ABORT: (system-error)
guile> (debug)
Frame 9 at test-suite/tests/r4rs.test:88:45
         ERROR: In procedure ttyname:
ERROR: No such file or directory
ABORT: (system-error)
guile>

this doesn't look promising.


>>
>> #0  0x00000001600d6bb4 in scm_is_pair (x=0x10001202cbd60) at inline.h:272
>> #1  0x0000000160086434 in scm_sloppy_assq (key=0x1200673a0,
>> alist=0x10001202cbd60) at alist.c:53
>> #2  0x00000001600d2a58 in scm_hash_fn_get_handle (table=0x120321ac0,
>> obj=0x1200673a0, hash_fn=0x1600d15ec <scm_ihashq>,
>>     assoc_fn=0x160086408 <scm_sloppy_assq>, closure=0x0) at hashtab.c:428
>> #3  0x00000001600d2e20 in scm_hash_fn_ref (table=0x12009aba0,
>> obj=0x1200673a0, dflt=0x4, hash_fn=0x1600d15ec <scm_ihashq>,
>>     assoc_fn=0x160086408 <scm_sloppy_assq>, closure=0x0) at hashtab.c:500
>> #4  0x00000001600d3304 in scm_hashq_ref (table=0x12009aba0,
>> key=0x1200673a0, dflt=0x4) at hashtab.c:613
>> #5  0x00000001600dc904 in module_variable (module=0x12009ab40,
>> sym=0x1200673a0) at modules.c:289
>> #6  0x00000001600dcabc in scm_eval_closure_lookup (eclo=0x1200f56d0,
>> sym=0x1200673a0, definep=0x4) at modules.c:337
>> #7  0x00000001600dcf38 in scm_sym2var (sym=0x1200673a0,
>> proc=0x1200f56d0, definep=0x4) at modules.c:461
>> #8  0x00000001600a2d6c in scm_lookupcar1 (vloc=0x12071b1e0,
>> genv=0x120228620, check=1) at eval.c:2861
>> #9  0x00000001600a73b0 in ceval (x=0x12071b1e0, env=0x120228620) at
>> eval.c:4027
>> #10 0x00000001600a4d54 in ceval (x=0x1202286d0, env=0x120228620) at
>> eval.c:3557
>> #11 0x00000001600a3cb4 in ceval (x=0x12071adc0, env=0x12071aa10) at
>> eval.c:3384
>> #12 0x00000001600aa168 in scm_apply (proc=0x1201522c0, arg1=0x404,
>> args=0x12071aa30) at eval.c:4997
>> #13 0x00000001600a90b0 in scm_call_0 (proc=0x12071aaa0) at eval.c:4651
> 
> This one is certainly trickier.  The stack trace above is that of a
> variable lookup (i.e., not related to regexps).  Can you try running
> `regexp.test' alone just to make sure?
> 
> Address X is 8-byte aligned, which corresponds to a non-immediate.
> Could you try printing (from the debugger) `* ((SCM *) x)' and
> `* ((SCM *) x + 1)'?

now I'm having some problems reproducing this.  I'll keep trying.

-Dan



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Ludovic Courtès]

Hi,

Dan McMahill <mcmahill@mtl.mit.edu> writes:

> Backtrace:
> In unknown file:
>    ?: 0* [primitive-load "test-suite/tests/r4rs.test"]
> In test-suite/tests/r4rs.test:
>  923: 1*
> Exception during displaying of backtrace: system-error
>
> test-suite/tests/r4rs.test:88:45: In procedure ttyname in expression
> (write (cons fun args) port):
> test-suite/tests/r4rs.test:88:45: No such file or directory
> ABORT: (system-error)
> guile> (debug)
> Frame 9 at test-suite/tests/r4rs.test:88:45
>         ERROR: In procedure ttyname:
> ERROR: No such file or directory
> ABORT: (system-error)
> guile>
>
> this doesn't look promising.

Well, it's much better than a segfault.  ;-)

This happens when trying to display a file port allegedly backed by a
TTY file descriptor.  See `fports.c:fport_print' (line 676):

    if (isatty (fdes))
      scm_display (scm_ttyname (exp), port);

What seems to be happening is that `isatty (fdes)' returns true but then
`ttyname (fdes)' fails.

I suspect that the port at hand is `(current-output-port)' or some
such.  On GNU/Linux, we get the following:

  guile> (ttyname (current-output-port))
  "/dev/pts/11"

Can you try this on your OS?

Thanks,
Ludovic.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Dan McMahill]

Ludovic Courtès wrote:
> Hi,
> 
> Dan McMahill <mcmahill@mtl.mit.edu> writes:
> 
>> Backtrace:
>> In unknown file:
>>    ?: 0* [primitive-load "test-suite/tests/r4rs.test"]
>> In test-suite/tests/r4rs.test:
>>  923: 1*
>> Exception during displaying of backtrace: system-error
>>
>> test-suite/tests/r4rs.test:88:45: In procedure ttyname in expression
>> (write (cons fun args) port):
>> test-suite/tests/r4rs.test:88:45: No such file or directory
>> ABORT: (system-error)
>> guile> (debug)
>> Frame 9 at test-suite/tests/r4rs.test:88:45
>>         ERROR: In procedure ttyname:
>> ERROR: No such file or directory
>> ABORT: (system-error)
>> guile>
>>
>> this doesn't look promising.
> 
> Well, it's much better than a segfault.  ;-)
> 
> This happens when trying to display a file port allegedly backed by a
> TTY file descriptor.  See `fports.c:fport_print' (line 676):
> 
>     if (isatty (fdes))
>       scm_display (scm_ttyname (exp), port);
> 
> What seems to be happening is that `isatty (fdes)' returns true but then
> `ttyname (fdes)' fails.
> 
> I suspect that the port at hand is `(current-output-port)' or some
> such.  On GNU/Linux, we get the following:
> 
>   guile> (ttyname (current-output-port))
>   "/dev/pts/11"
> 
> Can you try this on your OS?

I think it has to do with running inside of a chroot-ed environment. 
I'll have to try this out with guile-1.8.1, but with 1.6.8, this is what 
I see on Solaris-2.9/sparc:

chroot:

guile> (ttyname (current-output-port))
standard input:3:1: In procedure ttyname in expression (ttyname 
(current-output-port)):
standard input:3:1: No such file or directory
ABORT: (system-error)

Type "(backtrace)" to get more information or "(debug)" to enter the 
debugger.
guile> (version)
"1.6.8"


not chroot:

guile> (ttyname (current-output-port))
"/dev/pts/13"
guile> (version)
"1.6.8"

with 1.8.1 on this system, it works outside the chroot and I need to try 
in the chroot still.

I'll bet thats whats going on with NetBSD as well.  My failed tests are 
all inside a chroot environment.

-Dan



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Ludovic Courtès]

Hi,

Dan McMahill <mcmahill@mtl.mit.edu> writes:

> I'll bet thats whats going on with NetBSD as well.  My failed tests
> are all inside a chroot environment.

Well, we *could* modify the file port write (i.e., `fport_print ()') so
that it doesn't fail when `ttyname' does, if that's a common problem.

Or you could set up a chroot jail where `/dev/pts/*' are visible, if
that's the source of the problem.

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Ludovic Courtès]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Well, we *could* modify the file port write (i.e., `fport_print ()') so
> that it doesn't fail when `ttyname' does, if that's a common problem.
>
> Or you could set up a chroot jail where `/dev/pts/*' are visible, if
> that's the source of the problem.

Or, even better, we could modify `r4rs.test' so that it doesn't print
file ports.

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Dan McMahill]

Ludovic Courtès wrote:
> Hi,
> 
> Dan McMahill <mcmahill@mtl.mit.edu> writes:
> 
>> I'll bet thats whats going on with NetBSD as well.  My failed tests
>> are all inside a chroot environment.
> 
> Well, we *could* modify the file port write (i.e., `fport_print ()') so
> that it doesn't fail when `ttyname' does, if that's a common problem.
> 
> Or you could set up a chroot jail where `/dev/pts/*' are visible, if
> that's the source of the problem.


ok, I think this much smaller test case is instructive:

#include <stdio.h>
#include <unistd.h>

int main(int argc, char **argv)
{
         int fd = 0;
         char *n;

         printf ("isatty(%d) = %d\n", fd, isatty (fd));

         n = ttyname (fd);
         printf ("ttyname(%d) = \"%s\"\n", fd, n != NULL ? n : "unknown");

         return 0;
}


SunOS-5.9/sparc

chroot:

isatty(0) = 1
ttyname(0) = "unknown"

no chroot:

isatty(0) = 1
ttyname(0) = "/dev/pts/32"


NetBSD-2/alpha

chroot:

isatty(0) = 1
ttyname(0) = "unknown"

no chroot:

isatty(0) = 1
ttyname(0) = "/dev/ttyp2"

NetBSD-4/i386

chroot:

isatty(0) = 1
ttyname(0) = "/dev/ttyp2"

no chroot:

isatty(0) = 1
ttyname(0) = "/dev/ttyp1"


Wierd that the NetBSD-4 box doesn't seem to care about being in the 
chroot jail.




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Dan McMahill]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

>> I'm also working on getting this going on Solaris-2.9/sparc but am not
>> quite to the testsuite part.  I have a few bug fix patches there
>> too. Once I get my various problems worked out, I'll submit a more
>> cleaned up set of patches.

see the attached file for most of my patches.  One I didn't include in 
the tarfile is this one since I don't think you can universially (or 
maybe you can) assume -Wl,-Rpath is ok.  I wonder if the result of a 
configure test and maybe the --enable-rpath/--disable-rpath flag could 
be used to do the right thing here:


--- guile-config/guile-config.in.orig   2006-09-20 00:19:02.000000000 +0000
+++ guile-config/guile-config.in
@@ -155,7 +155,7 @@
                 (if (or (string=? libdir "/usr/lib")
                         (string=? libdir "/usr/lib/"))
                    ""
-                  (string-append "-L" (get-build-info 'libdir)))
+                  (string-append "-Wl,-R" (get-build-info 'libdir) " 
-L" (get-build-info 'libdir)))
                (string-join other-flags)

                )))



-Dan

[-- Attachment #2: guile-1.8.1-patches.tar.gz --]
[-- Type: application/gzip, Size: 4022 bytes --]

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Ludovic Courtès]

Hi,

Dan McMahill <mcmahill@mtl.mit.edu> writes:

>>> I'm also working on getting this going on Solaris-2.9/sparc but am not
>>> quite to the testsuite part.  I have a few bug fix patches there
>>> too. Once I get my various problems worked out, I'll submit a more
>>> cleaned up set of patches.
>
> see the attached file for most of my patches.

[...]

> --- guile-config/guile-config.in.orig   2006-09-20 00:19:02.000000000 +0000
> +++ guile-config/guile-config.in
> @@ -155,7 +155,7 @@
>                 (if (or (string=? libdir "/usr/lib")
>                         (string=? libdir "/usr/lib/"))
>                    ""
> -                  (string-append "-L" (get-build-info 'libdir)))
> +                  (string-append "-Wl,-R" (get-build-info 'libdir) "
> -L" (get-build-info 'libdir)))
>                (string-join other-flags)
>
>                )))

Can you explain why this is needed?  `guile-config' is only used by
applications that link against Guile.  Did you have troubles compiling
such applications?

Besides, `-Wl,-R' can probably not be considered portable.

Thanks,
Ludovic.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Dan McMahill]

Ludovic Courtès wrote:
> Hi,
> 
> Dan McMahill <mcmahill@mtl.mit.edu> writes:
> 
>>>> I'm also working on getting this going on Solaris-2.9/sparc but am not
>>>> quite to the testsuite part.  I have a few bug fix patches there
>>>> too. Once I get my various problems worked out, I'll submit a more
>>>> cleaned up set of patches.
>> see the attached file for most of my patches.
> 
> [...]
> 
>> --- guile-config/guile-config.in.orig   2006-09-20 00:19:02.000000000 +0000
>> +++ guile-config/guile-config.in
>> @@ -155,7 +155,7 @@
>>                 (if (or (string=? libdir "/usr/lib")
>>                         (string=? libdir "/usr/lib/"))
>>                    ""
>> -                  (string-append "-L" (get-build-info 'libdir)))
>> +                  (string-append "-Wl,-R" (get-build-info 'libdir) "
>> -L" (get-build-info 'libdir)))
>>                (string-join other-flags)
>>
>>                )))
> 
> Can you explain why this is needed?  `guile-config' is only used by
> applications that link against Guile.  Did you have troubles compiling
> such applications?

With that I don't have to modify the guile-config output.  In other 
words by default I might just get "-L/my/guile/path/lib" where I may 
actually want "-L/my/guile/path/lib -Wl,-R/my/guile/path/lib".

> Besides, `-Wl,-R' can probably not be considered portable.
which is why one would need a test for it.

Anyway, I figured this one was questionable for general consumption 
which is why I kept it apart from the others.

-Dan




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Ludovic Courtès]

Hi,

Dan McMahill <mcmahill@mtl.mit.edu> writes:

> With that I don't have to modify the guile-config output.  In other
> words by default I might just get "-L/my/guile/path/lib" where I may
> actually want "-L/my/guile/path/lib -Wl,-R/my/guile/path/lib".

Greg Troxel <gdt@ir.bbn.com> writes:

> Probably you are right.  But not having a way to include some sort of
> rpath when needed isn't portable either.

Doesn't Libtool solve this problem?  That is, if you installed the
Libtool archive `libguile.la' and link _using Libtool_ against it, then
passing `-L/my/guile/path/lib' is enough and Libtool sets up the new
library's RPATH correspondingly.

Granted, you don't necessarily use Libtool, and the `.la' file could be
unavailable, but that's another story...

Thanks,
Ludovic.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Greg Troxel]

[-- Attachment #1.1: Type: text/plain, Size: 1075 bytes --]


ludo@chbouib.org (Ludovic Courtès) writes:

> Dan McMahill <mcmahill@mtl.mit.edu> writes:
>
>> With that I don't have to modify the guile-config output.  In other
>> words by default I might just get "-L/my/guile/path/lib" where I may
>> actually want "-L/my/guile/path/lib -Wl,-R/my/guile/path/lib".
>
> Greg Troxel <gdt@ir.bbn.com> writes:
>
>> Probably you are right.  But not having a way to include some sort of
>> rpath when needed isn't portable either.
>
> Doesn't Libtool solve this problem?  That is, if you installed the
> Libtool archive `libguile.la' and link _using Libtool_ against it, then
> passing `-L/my/guile/path/lib' is enough and Libtool sets up the new
> library's RPATH correspondingly.
>
> Granted, you don't necessarily use Libtool, and the `.la' file could be
> unavailable, but that's another story...

Sure, but guile-config is documented to work for programs linking
without libtool.

I think guile should have a .pc file for pkg-config and guile-config
should be deprecated eventually.  That's really orthogonal.


[-- Attachment #1.2: Type: application/pgp-signature, Size: 185 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Ludovic Courtès]

Hi,

Greg Troxel <gdt@ir.bbn.com> writes:

> I think guile should have a .pc file for pkg-config and guile-config
> should be deprecated eventually.  That's really orthogonal.

Yeah, that's probably the way to go.  It's also more
cross-compilation-friendly I think.

Thanks,
Ludovic.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Greg Troxel]

[-- Attachment #1.1: Type: text/plain, Size: 2205 bytes --]


ludo@chbouib.org (Ludovic Courtès) writes:

> Greg Troxel <gdt@ir.bbn.com> writes:
>
>> I think guile should have a .pc file for pkg-config and guile-config
>> should be deprecated eventually.  That's really orthogonal.
>
> Yeah, that's probably the way to go.  It's also more
> cross-compilation-friendly I think.

There's a huge advantage in being standard.  pkgsrc on NetBSD basically
has to add -R to lots of things.  There's support in pkgsrc for dealing
with this for pkgconfig that's very easy to use.

pkg-config also can be built as a host tool, which the cross-compile
framework would have to deal with only once.

example:

In pkgsrc/devel/at-spi/Makefile there is:

PKGCONFIG_OVERRIDE+=	cspi-1.0.pc.in
PKGCONFIG_OVERRIDE+=	libspi-1.0.pc.in

and pkgsrc/mk/configure/pkg-config-override.mk has code to sed the
platform-appropriate RPATH flags into the Libs: line:


# $NetBSD: pkg-config-override.mk,v 1.2 2006/07/10 16:12:20 jlam Exp $

######################################################################
### pkg-config-override (PRIVATE)
######################################################################
### pkg-config-override inserts the compiler's "rpath" flag into
### pkg-config data files so that ``pkg-config --ldflags <module>'' will
### return the full set of compiler flags needed to find libraries at
### run-time.
###
.PHONY: pkg-config-override
pkg-config-override:
	@${DO_NADA}

.if defined(_USE_RPATH) && !empty(_USE_RPATH:M[yY][eE][sS])
pkg-config-override: subst-pkgconfig

PKGCONFIG_OVERRIDE_SED=	\
	'/^Libs:.*[ 	]/s|-L\([ 	]*[^ 	]*\)|${COMPILER_RPATH_FLAG}\1 -L\1|g'
PKGCONFIG_OVERRIDE_STAGE?=	pre-configure

SUBST_CLASSES+=			pkgconfig
.  if ${PKGCONFIG_OVERRIDE_STAGE} == "pre-configure"
SUBST_STAGE.pkgconfig=		do-configure-pre-hook
.  elif ${PKGCONFIG_OVERRIDE_STAGE} == "post-configure"
SUBST_STAGE.pkgconfig=		do-configure-post-hook
.  else
SUBST_STAGE.pkgconfig=		${PKGCONFIG_OVERRIDE_STAGE}
.  endif
SUBST_MESSAGE.pkgconfig=	Adding run-time search paths to pkg-config files.
SUBST_FILES.pkgconfig=		${PKGCONFIG_OVERRIDE:S/^${WRKSRC}\///}
SUBST_SED.pkgconfig=		${PKGCONFIG_OVERRIDE_SED}
.endif


[-- Attachment #1.2: Type: application/pgp-signature, Size: 185 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Greg Troxel]

I have this patch lying around from adding pkgconfig support long ago; I
think I sent it and there wasn't much interest then.



Index: Makefile.am
===================================================================
RCS file: /QUIST-CVS/guile/Makefile.am,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 Makefile.am
--- Makefile.am	2002/12/07 22:41:28	1.1.1.3
+++ Makefile.am	2003/02/27 14:36:25
@@ -29,7 +29,7 @@
 include_HEADERS = libguile.h
 
 EXTRA_DIST = HACKING GUILE-VERSION ANON-CVS SNAPSHOTS \
-	     $(ACLOCAL) BUGS README-PACKAGING
+	     $(ACLOCAL) BUGS README-PACKAGING guile.pc.in
 
 TESTS = check-guile
 
@@ -37,5 +37,8 @@
 
 # The rule will cd to $(top_srcdir).
 ACLOCAL = ./guile-aclocal.sh
+
+pkgconfigdir = $(libdir)/pkgconfig
+pkgconfig_DATA = guile.pc
 
 # Makefile.am ends here
Index: configure.in
===================================================================
RCS file: /QUIST-CVS/guile/configure.in,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 configure.in
--- configure.in	2002/12/08 01:48:52	1.1.1.3
+++ configure.in	2003/02/27 14:37:37
@@ -745,6 +745,8 @@
 AC_CONFIG_FILES([libguile/guile-snarf-docs],
                 [chmod +x libguile/guile-snarf-docs])
 
+AC_CONFIG_FILES([guile.pc])
+
 AC_OUTPUT
 
 dnl Local Variables:
Index: guile.pc.in
===================================================================
RCS file: guile.pc.in
diff -N guile.pc.in
--- /dev/null	Thu Feb 27 03:35:16 2003
+++ guile.pc.in	Thu Feb 27 09:37:37 2003
@@ -0,0 +1,12 @@
+# pkgconfig file for guile
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: guile
+Version: 1.6
+Description: guile extension language
+Requires:
+Libs: -L${libdir} -lguile -lguile-ltdl @LDFLAGS@ @LIBS@
+Cflags: -I${includedir}



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Ludovic Courtès]

Hi,

Greg Troxel <gdt@ir.bbn.com> writes:

> I have this patch lying around from adding pkgconfig support long ago; I
> think I sent it and there wasn't much interest then.

FWIW, I'm all in favor of applying such a patch.  We could keep
`guile-config' for compatibility and have it invoke `pkg-config'
appropriately.

It might even be acceptable for 1.8 if we can do this.

Thanks!

Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Greg Troxel]

ludo@chbouib.org (Ludovic Courtès) writes:

>> --- guile-config/guile-config.in.orig   2006-09-20 00:19:02.000000000 +0000
>> +++ guile-config/guile-config.in
>> @@ -155,7 +155,7 @@
>>                 (if (or (string=? libdir "/usr/lib")
>>                         (string=? libdir "/usr/lib/"))
>>                    ""
>> -                  (string-append "-L" (get-build-info 'libdir)))
>> +                  (string-append "-Wl,-R" (get-build-info 'libdir) "
>> -L" (get-build-info 'libdir)))
>>                (string-join other-flags)
>>
>>                )))
>
> Can you explain why this is needed?  `guile-config' is only used by
> applications that link against Guile.  Did you have troubles compiling
> such applications?

Sorry if this is stuff everyone knows, but..

There are several ways that programs find shared libraries at runtime.
Some of my info is old, so sorry if I am incorrect:

debian way: -rpath is evil.  all libs are in /usr/lib, or use ld.so.conf
or ldconfig of some kind

netbsd way: by default, /usr and /usr/lib are searched.  ldconfig is
messy and LD_LIBRARY_PATH is a gross hack for other than debugging.
Programs should be compiled with -R for directories that are to be
searched at runtime.  In particular, /usr/local/lib and /usr/pkg/lib are
not in the default library search path.

darwin way: absolute path is resolved at link time, and stored, so you
get the same library you linked with (not quite sure on this).

> Besides, `-Wl,-R' can probably not be considered portable.

Probably you are right.  But not having a way to include some sort of
rpath when needed isn't portable either.

My view is that the right answer from a portability viewpoint is to be
aware of the rpath issue and to detect at configure time what the  local
rules are and then follow them.

So probably --enable-rpath at configure should subsistute #t for
@WANT_RPATH@ (instead of #f without) and the code above could be
conditional.

I've had to do similar things on various bits of guile over the years.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: debugging guile test failure and segfault.

[Andy Wingo]

Hi Greg,

On Sun, 2007-06-10 at 13:46 -0400, Greg Troxel wrote:
> There are several ways that programs find shared libraries at runtime.
> Some of my info is old, so sorry if I am incorrect:
> 
> debian way: -rpath is evil.  all libs are in /usr/lib, or use ld.so.conf
> or ldconfig of some kind
> 
> netbsd way: by default, /usr and /usr/lib are searched.  ldconfig is
> messy and LD_LIBRARY_PATH is a gross hack for other than debugging.
> Programs should be compiled with -R for directories that are to be
> searched at runtime.  In particular, /usr/local/lib and /usr/pkg/lib are
> not in the default library search path.
> 
> darwin way: absolute path is resolved at link time, and stored, so you
> get the same library you linked with (not quite sure on this).

This is informative, thanks.

Andy.
-- 
http://wingolog.org/



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user