public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: "make check" tests wrong library
       [not found] <199806221254.OAA32404@jolan.ppro>
@ 1998-06-23 14:01 ` Jeffrey A Law
  0 siblings, 0 replies; 3+ messages in thread
From: Jeffrey A Law @ 1998-06-23 14:01 UTC (permalink / raw)
  To: Carlo Wood; +Cc: egcs

  In message <199806221254.OAA32404@jolan.ppro>you write:
  > Ok, don't take me wrong :).  I was not trying to push anyone to add
  > a patch to the egcs distribution; I agree with you that this is
  > something that needs to fixed in dejagnu - not egcs.
No worries.  What we need to find out is why the code  to handle this
isn't working in your situation.

There's two routines to look at in dejagnu.

g++_link_flags and libstdc++_link_flags in libgloss.exp from the
dejagnu tree.

Both know how to search a set of directories looking for libraries.

I'm not a tcl expert, so I usually debug that code with a few well
placed "send_user" commands.

You'll want to know whether or not ${gccpath} has a value (and what
the value is).  That determines how the testing hardness tries to
find libraries.  Once you've got that tidbit we'll dig further.



jeff

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: "make check" tests wrong library
  1998-06-21 17:16 Carlo Wood
@ 1998-06-21 23:07 ` Jeffrey A Law
  0 siblings, 0 replies; 3+ messages in thread
From: Jeffrey A Law @ 1998-06-21 23:07 UTC (permalink / raw)
  To: Carlo Wood; +Cc: egcs

  In message < 199806220012.CAA24588@jolan.ppro >you write:
  > The first time I run "make check" I had never done a "make install"
  > before, and all checks of libstdc++ FAILed, see my report at
  > http://www.cygnus.com/ml/egcs/1998-Jun/0715.html .
  > 
  > After *installing* egcs, "make check" suddenly succeeds for 100%.
  > This made me a bit suspicious, so I looked in .../testsuite/libstdc++.log
  > to find:
This would indicate a problem in the testing harness.  It is supposed to
know how to find the right libstdc++ during the testing phase.

jeff

^ permalink raw reply	[flat|nested] 3+ messages in thread

* "make check" tests wrong library
@ 1998-06-21 17:16 Carlo Wood
  1998-06-21 23:07 ` Jeffrey A Law
  0 siblings, 1 reply; 3+ messages in thread
From: Carlo Wood @ 1998-06-21 17:16 UTC (permalink / raw)
  To: egcs

The first time I run "make check" I had never done a "make install"
before, and all checks of libstdc++ FAILed, see my report at
http://www.cygnus.com/ml/egcs/1998-Jun/0715.html .

After *installing* egcs, "make check" suddenly succeeds for 100%.
This made me a bit suspicious, so I looked in .../testsuite/libstdc++.log
to find:

                === libstdc++ tests ===

Running target unix
Using /usr/local/bin/../share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/local/bin/../share/dejagnu/config/unix.exp as generic interface file for target.
Using ../../../../egcs-1.0.3a/libstdc++/testsuite/config/default.exp as tool-and-target-specific interface file.
Running ../../../../egcs-1.0.3a/libstdc++/testsuite/libstdc++.tests/test.exp ...
Executing on host: /usr/src/egcs/egcs-1.0.3a-objdir/gcc/xgcc -B/usr/src/egcs/egcs-1.0.3a-objdir/gcc/ ../../../../egcs-1.0.3a/libstdc++/testsuite/libstdc++.tests/../../tests/tcomplex.cc  -I.. -I../../../../egcs-1.0.3a/libstdc++/testsuite/.. -I../../../../egcs-1.0.3a/libstdc++/testsuite/../stl -I.   -g -L/usr/src/egcs/egcs-1.0.3a-objdir/libraries/libstdc++/testsuite/../../libstdc++ -lstdc++  -lm   -o /usr/src/egcs/egcs-1.0.3a-objdir/libraries/libstdc++/testsuite/tcomplex
PASS: tcomplex.cc compilation
[...etc...]

The executable `tcomplex' is still there - but also after recompiling it
with the command above - we see that:

/usr/src/egcs/egcs-1.0.3a-objdir/libraries/libstdc++/testsuite>ldd tcomplex
        libstdc++.so.2.8 => /usr/local/egcs/lib/libstdc++.so.2.8 (0x40003000)
        libm.so.6 => /lib/libm.so.6 (0x40042000)
        libc.so.6 => /lib/libc.so.6 (0x4005b000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)

... it uses the *installed* libstdc++.so.2.8.
And NOT the libstdc++ that I just compiled:

>ls /usr/src/egcs/egcs-1.0.3a-objdir/libraries/libstdc++/lib*
/usr/src/egcs/egcs-1.0.3a-objdir/libraries/libstdc++/libstdc++.a
/usr/src/egcs/egcs-1.0.3a-objdir/libraries/libstdc++/libstdc++.so@
/usr/src/egcs/egcs-1.0.3a-objdir/libraries/libstdc++/libstdc++.so.2.8@
/usr/src/egcs/egcs-1.0.3a-objdir/libraries/libstdc++/libstdc++.so.2.8.0*

Although in this case the installed library and the test-case library
is the same, it doesn't matter.  But because I won't install every
snapshot - and because I see explicitly the
-L/usr/src/egcs/egcs-1.0.3a-objdir/libraries/libstdc++/testsuite/../../libstdc++in the compile statement, I do assume this is not what is intended.

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

Note that this "make check", as well as the first run, was done with
dejagnu-971222 without patches.

After applying H.J. Lu's lookfor_dir_with_trigger patch to dejagnu-971222,
I re-did the "make check" and found the following:

                === libstdc++ Summary ===

# of expected passes            30

(Of course).  And:

/usr/src/egcs/egcs-1.0.3a-objdir/libraries/libstdc++/testsuite>ldd tcomplex
        libstdc++.so.2.8 => /usr/src/egcs/egcs-1.0.3a-objdir/libraries/libstdc++/libstdc++.so.2.8 (0x40000000)
        libm.so.6 => /lib/libm.so.6 (0x40046000)
        libc.so.6 => /lib/libc.so.6 (0x4005f000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)

I hope this is a good reason to honour H.J. Lu request and use his patch.

Regards,

Carlo Wood

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1998-06-23 14:01 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <199806221254.OAA32404@jolan.ppro>
1998-06-23 14:01 ` "make check" tests wrong library Jeffrey A Law
1998-06-21 17:16 Carlo Wood
1998-06-21 23:07 ` Jeffrey A Law

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).