pty.so: [BUG] Segmentation fault - still

[Bob Gustafson]

As suggested in an earlier email, I blew away /usr/local/lib/ruby - which
took care of the subdirectories 1.6, 1.8, and site_ruby.

I also deleted libruby-static.a which was in /usr/local/lib. (This file was
regenerated during the rebuild process below - a bit odd?)

Then I untarred the distribution file, did:

./configure 2>&1 | tee config.out
make 2>&1 | tee make.out
make test 2>&1 | tee test.out
make install 2?&1 | tee install.out

ruby testbug.rb

I got exactly the same result as before:

bash-2.03# ruby bugtest.rb
/usr/local/lib/ruby/1.8/sparc-solaris2.7/pty.so: [BUG] Segmentation fault
ruby 1.8.1 (2003-12-25) [sparc-solaris2.7]

Abort (core dumped)
bash-2.03#
bash-2.03# cat bugtest.rb
require 'pty'
puts "This is a test"
bash-2.03#


If you are interested in looking at the output of the build phases (*.out),
I put tham up on http://66.175.1.68/rubybug.html

Thanks for any help.

Bob Gustafson

Joel VanderWerf wrote in [ruby-talk: 91779]

Hi,

At Sun, 8 Feb 2004 07:11:47 +0900,
Joel VanderWerf wrote in [ruby-talk:91760]:

Is it possible that the include path found version.h in
$PREFIX/lib/ruby/1.8/sparc-solaris2.7/ before the one in the build dir?
I've never seen this problem on linux, and I don't recall seeing it
before on solaris.

No.


A typical compiler invocation looks like:

gcc -I/usr/path/include -I. -I. -I/usr/path/include -c class.c

It is strange. Don't you set CFLAGS env? Otherwise, '-g -O2'
should appear instead.

Oops. That's exactly what it was. I have:

declare -x CFLAGS="-I/usr/path/include"

That was for some other software. Good to know that can interfere with
ruby builds. Thanks.

 

[ts]

B> If you are interested in looking at the output of the build phases (*.out),
B> I put tham up on http://66.175.1.68/rubybug.html

This is the problem

checking whether the linker is GNU ld... yes

It work fine with

moulon% gcc -v
Reading specs from /opt/gcc/lib/gcc-lib/sparc-sun-solaris2.7/3.3.2/specs
Configured with: ../gcc-3.3.2/configure --prefix=/opt/gcc --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls
Thread model: posix
gcc version 3.3.2
moulon%

See --with-as and --with-ld

 

[Bob Gustafson]

Hmm, perhaps I am working with a collection of old cats and dogs - gcc
2.95.2 and Sun linker.

The 'make test' in the Ruby build suite is a bit optimistic maybe?

# date
Mon Feb 9 09:55:45 CST 2004
# gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs
gcc version 2.95.2 19991024 (release)
#

# ld -V
ld: Software Generation Utilities - Solaris Link Editors: 5.7-1.280
# as -V
GNU assembler version 2.13 (sparc-sun-solaris2.7) using BFD version 2.13

BobG

 

[ts]

B> # gcc -v
B> Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs
B> gcc version 2.95.2 19991024 (release)
B> #

Well, you have an old compiler, but the problem is here

B> # ld -V
B> ld: Software Generation Utilities - Solaris Link Editors: 5.7-1.280

The linker for gcc is configured *at compile time* (when you compile gcc)
and not at runtime and apparently your gcc was compiled with the GNU ld
and not the Solaris ld

try this to see which ld is called

touch /tmp/a.c
gcc -v /tmp/a.c



Guy Decoux

 

[Bob Gustafson]

Hmm, lots of stuff

# date
Mon Feb 9 15:51:40 CST 2004
# touch /tmp/a.c
# gcc -v /tmp/a.c
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs
gcc version 2.95.2 19991024 (release)
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/cpp -lang-c -v -D__GNUC__=2
-D__GNUC_MINOR__=95 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__sparc__
-D__sun
__ -D__unix__ -D__svr4__ -D__SVR4 -D__sparc -D__sun -D__unix -Asystem(unix)
-Asy
stem(svr4) -D__GCC_NEW_VARARGS__ -Acpu(sparc) -Amachine(sparc) /tmp/a.c
/var/tmp
/ccgVUTGM.i
GNU CPP version 2.95.2 19991024 (release) (sparc)
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/../../../../sparc-sun-solari
s2.7/include
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/include
/usr/include
End of search list.
The following default directories have been omitted from the search path:
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/../../../../include/g++-3
End of omitted list.
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/cc1 /var/tmp/ccgVUTGM.i
-qui
et -dumpbase a.c -version -o /var/tmp/ccYD6mJs.s
GNU C version 2.95.2 19991024 (release) (sparc-sun-solaris2.7) compiled by
GNU C
version 2.95.2 19991024 (release).
/usr/local/sparc-sun-solaris2.7/bin/as -V -Qy -s -o /var/tmp/cc6FNEaa.o
/var/tm
p/ccYD6mJs.s
GNU assembler version 2.13 (sparc-sun-solaris2.7) using BFD version 2.13
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/collect2 -V -Y
P,/usr/ccs/li
b:/usr/lib -Qy /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crt1.o
/usr/lo
cal/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crti.o /usr/ccs/lib/values-Xa.o
/usr
/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crtbegin.o
-L/usr/local/lib/gcc-l
ib/sparc-sun-solaris2.7/2.95.2 -L/usr/local/sparc-sun-solaris2.7/lib
-L/usr/ccs/
bin -L/usr/ccs/lib -L/usr/local/lib /var/tmp/cc6FNEaa.o -lgcc -lc -lgcc
/usr/loc
al/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crtend.o
/usr/local/lib/gcc-lib/sparc
-sun-solaris2.7/2.95.2/crtn.o
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crt1.o: In function
`_start':
/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crt1.o(.text+0x5c):
undefined
reference to `main'
GNU ld version 2.13
Supported emulations:
elf32_sparc
elf64_sparc
collect2: ld returned 1 exit status
#




Guy Decoux wrote in rubytalk [92487]

 

[ts]

Like I've said previously this is the problem

B> GNU assembler version 2.13 (sparc-sun-solaris2.7) using BFD version 2.13
B> GNU ld version 2.13

use a gcc compiled with /usr/ccs/bin/as and /usr/ccs/bin/ld

You have pre-compiled version on http://sunfreeware.com/


Guy Decoux

 

[Daniel Berger]

Like I've said previously this is the problem

B> GNU assembler version 2.13 (sparc-sun-solaris2.7) using BFD version 2.13
B> GNU ld version 2.13

use a gcc compiled with /usr/ccs/bin/as and /usr/ccs/bin/ld

You have pre-compiled version on http://sunfreeware.com/


Guy Decoux

I've noticed that in general, upgrading to gcc 3.3.2 on Solaris has
solved a lot of problems.

Regards,

Dan

 

[Park Heesob]

Hi, I reresend this message.

Hi Alex,

Just some ideas for the web page to get you started.
Let's go with a "mission statement" (ack!) and some
bio information (including your own). Park and
Shashank, if you're willing please send some bio
information to Alex as well for the web page.

Dan

Project Goals
=============
The goal of this project is to make Ruby an excellent
choice for developing on the Win32 platform. Ruby has
lagged behind Perl and, especially, Python in the
Win32 arena. We intend to not only equal Perl and
Python in terms of Win32 development viability, but
surpass them both in terms of a superior API and
additional packages.

Bio: Daniel J. Berger (Project Leader)
======================================
Originally a student of Classical History, Daniel
Berger became a computer programmer when he joined the
US Air Force in late 1995 where he learned ADA, C and
Perl. After getting out of the military in 1999, he
eventually found a job working for US West (now Qwest)
as a Perl/Tk programmer. He eventally discovered Ruby
in 2001 or so, and has been enamored ever since.

These days Daniel spends most of his time developing
production support applications using Ruby, along with
a healthy dose of Oracle database interaction.

Daniel has numerous packages on the RAA as well as a
few Perl modules on CPAN.

I will intruduce myself.

I was born before one year of the Apollo 11 missoin.

I started computer programming in 1983 with BASIC on 8bit machine.

I have become interested in languages both human and computer languages.

I specialized in physics at the university in 1987.

I have studied several human languages like English, French, German,
Spanish, Russian, Japanese, Chinese and Latin in my college days.

But I cannot speak fluently any of them

Besides, I also have studied several programming languages like Assembly,
Pascal, C, C++, BASIC, Prolog, FORTRAN, COBOL, Ada, Modula, Smalltalk etc
during my college life.

I found a job at a small company called HANGANG Systems after graduation.

Since then going through some companies I learned by experience various
environments: Windows, Linux, SUN, HP, DEC, Oracle, Informix, SQL, Motif,
Apache, PHP, ASP, Java etc.

I took part in Korean broadcasting satellite control system coworked with
ETRI and a company Teltek located at Vancouver,Canada in 1995.

I developed the Ozone Monitoring and Alarming System for Korean Ministry of
Environment in 1998.

I met Ruby accidentally at computer magazine in 2000.

I made some solutions with Ruby in company such as real-time meta search
engine, doname name whois query, calendar system conversion, web auto
scripting.

I contribued for Ruby community with a little extension libraries like
wxRuby, PCRE, win32-popen etc.

Now I'm working at a small company called INDI Systems, Inc.
(http://www.indi-tech.com/default.asp)

Edit for your purpose.

Regards,

Park Heesob

 

[romerun]

After the release of the "superior API"/additional packages,
People will compile them into parrot VM,
then both Perl and Python can call those library as if
the library were written in their languages.

Ruby can do the samething vis versa.

Why reinvent the wheel ..

 

[Daniel Berger]

Well, first let me say that this post was made accidentally by Park to
this newsgroup. It was meant as a private email for our web guy.

After the release of the "superior API"/additional packages,
People will compile them into parrot VM,
then both Perl and Python can call those library as if
the library were written in their languages.

Ruby can do the samething vis versa.

Why reinvent the wheel ..

Possible answers:

1) Because I don't feel like waiting 2-3 years for Parrot to be
finished.
2) Because in some cases the Win32 API calls the Python and
(especially) Perl libraries use are deprecated.
3) Because in some cases the Perl and Python libraries don't support
everything we currently, or plan to, support, e.g. asynchronous named
pipes (now in CVS btw).
4) Because I can.

Regards,

Daniel Berger
Win32 Utils Project Lead