Followup on HPUX build issue

R

Robert Nesius

It looks like the problem is that the Makefile for ext/pty defines in
CPP_FLAGS -DHAVE_GLIBC or -DHAVE_OPENPTY (something along those lines -
don't have the build area handy right now), and also includes -lutil in
LIBS. Looks like this was done unconditionally? In any case, after
tweaking those lines in the make file the pty extension at least
compiled. If this wasn't the right list for my question/follow-up,
apologies in advance.

Cheers,

-Rob
 
N

nobu.nokada

Hi,

At Tue, 31 Aug 2004 11:19:03 +0900,
Robert Nesius wrote in [ruby-talk:111049]:
It looks like the problem is that the Makefile for ext/pty defines in
CPP_FLAGS -DHAVE_GLIBC or -DHAVE_OPENPTY (something along those lines -
don't have the build area handy right now), and also includes -lutil in
LIBS. Looks like this was done unconditionally? In any case, after
tweaking those lines in the make file the pty extension at least
compiled. If this wasn't the right list for my question/follow-up,
apologies in advance.

It should be done by have_library("util", "openpty") in
extconf.rb. Can't you show the mkmf.log?
 
N

nesius

Hi,

At Tue, 31 Aug 2004 11:19:03 +0900,
Robert Nesius wrote in [ruby-talk:111049]:
It looks like the problem is that the Makefile for ext/pty defines in
CPP_FLAGS -DHAVE_GLIBC or -DHAVE_OPENPTY (something along those lines -
don't have the build area handy right now), and also includes -lutil in
LIBS. Looks like this was done unconditionally? In any case, after
tweaking those lines in the make file the pty extension at least
compiled. If this wasn't the right list for my question/follow-up,
apologies in advance.

It should be done by have_library("util", "openpty") in
extconf.rb. Can't you show the mkmf.log?

Sorry - I did not know about the mkmf.log until you pointed me at it.
I build Open Source tools all of the time. The ruby build has always
been a bit of a mystery to me in terms of how it is architected.
In any case, upon looking at this log file I was able to root cause
the failure mode that was causing ruby to think it had access
to 'util.h' and -lutil.

Basically, the build assumes it is using gcc, and when built
with HPs ansic compiler it encounters a failure mode that
leads the build to conclude the test succeeded vs. failed.

The test is:
$CC -o conftest $CFLAGS -lutil -E conftest.c

-E tells both gcc and ansic to dump the pre-processor output.
gcc interprets -o as a directive to dump the output into conftest.
/opt/ansic/bin/cc, when it sees -E, does not understand -o.
it just dumps the output to stdout. A better way to do this
when using ansic is to use the '-P' directive, like so:
$CC $CFLAGS -P conftest.c. The preprocessor output will
be put into conftest.i.

I tried using gcc but ran into another failure mode, and I much
prefer using HPs ansic compiler on HPUX because it produces
much much tighter code than gcc does.

On HPUX give me Ruby and Perl compiled with ansic over
perl/ruby compiled with gcc any day of the week and
twice on Sunday.

-Rob
 
N

nesius

Hi,

At Tue, 31 Aug 2004 11:19:03 +0900,
Robert Nesius wrote in [ruby-talk:111049]:
It looks like the problem is that the Makefile for ext/pty defines in
CPP_FLAGS -DHAVE_GLIBC or -DHAVE_OPENPTY (something along those lines -
don't have the build area handy right now), and also includes -lutil in
LIBS. Looks like this was done unconditionally? In any case, after
tweaking those lines in the make file the pty extension at least
compiled. If this wasn't the right list for my question/follow-up,
apologies in advance.

It should be done by have_library("util", "openpty") in
extconf.rb. Can't you show the mkmf.log?

Sorry - I did not know about the mkmf.log until you pointed me at it.
I build Open Source tools all of the time. The ruby build has always
been a bit of a mystery to me in terms of how it is architected.
In any case, upon looking at this log file I was able to root cause
the failure mode that was causing ruby to think it had access
to 'util.h' and -lutil.

Basically, the build assumes it is using gcc, and when built
with HPs ansic compiler it encounters a failure mode that
leads the build to conclude the test succeeded vs. failed.

The test is:
$CC -o conftest $CFLAGS -lutil -E conftest.c

-E tells both gcc and ansic to dump the pre-processor output.
gcc interprets -o as a directive to dump the output into conftest.
/opt/ansic/bin/cc, when it sees -E, does not understand -o.
it just dumps the output to stdout. A better way to do this
when using ansic is to use the '-P' directive, like so:
$CC $CFLAGS -P conftest.c. The preprocessor output will
be put into conftest.i.

I tried using gcc but ran into another failure mode, and I much
prefer using HPs ansic compiler on HPUX because it produces
much much tighter code than gcc does.

On HPUX give me Ruby and Perl compiled with ansic over
perl/ruby compiled with gcc any day of the week and
twice on Sunday.

-Rob

To follow up my own post, here's the problem with gcc.
When using gcc, the build sends HP Linker flags into gnu's ld.
When using cc, the build uses HPs linker and sends in HP Linker flags.

If you need examples let me know and I'll reproduce and
dump logs. I'm not 100% savvy about how this build is
architected so if there are specific logs you want let me know.

-Rob
 
N

nobu.nokada

Hi,

At Wed, 1 Sep 2004 05:55:10 +0900,
nesius wrote in [ruby-talk:111144]:
The test is:
$CC -o conftest $CFLAGS -lutil -E conftest.c

-E tells both gcc and ansic to dump the pre-processor output.
gcc interprets -o as a directive to dump the output into conftest.
/opt/ansic/bin/cc, when it sees -E, does not understand -o.
it just dumps the output to stdout. A better way to do this
when using ansic is to use the '-P' directive, like so:
$CC $CFLAGS -P conftest.c. The preprocessor output will
be put into conftest.i.

Thank you, I got it. RUBY_CPPOUTFILE in configure.in seems not
to be working.

Try this patch with deleting config.cache file.


Index: configure.in
===================================================================
RCS file: /cvs/ruby/src/ruby/configure.in,v
retrieving revision 1.245
diff -u -2 -p -r1.245 configure.in
--- configure.in 30 Aug 2004 06:16:29 -0000 1.245
+++ configure.in 1 Sep 2004 01:31:31 -0000
@@ -23,4 +23,5 @@ AC_DEFUN(RUBY_CPPOUTFILE,
CPPFLAGS='-o conftest.i'
AC_TRY_CPP([], rb_cv_cppoutfile=yes, rb_cv_cppoutfile=no)
+test -f conftest.i || rb_cv_cppoutfile=no
CPPFLAGS=$cppflags
rm -f conftest*])
 
N

nesius

Thanks, I will try that out.

There are some other problems with the ruby build you should
know about.

First off, the link is not given CFLAGS or LDFLAGS, so I
must set CC to not only define the compiler, but define
all of the other flags I need during the link. I need
to pass in mainly directives to find shared libraries
because my shared libraries do not exist in paths that
exist in ldso.conf.

So, because my libraries are not found by the system, and ruby
performs its link with CFLAGS or LDFLAGS, I have to do
something ugly like this:

-----
# This one rejects CFLAGS and LDFLAGS during link, and links with CC
# So, I'm putting CFLAGS into CC
export CC="$CC $CFLAGS"
-----

This also causes problems when trying to build a 64-bit ruby on
HPUX 11.00 because if +DA2.0W is not seen on the command line
when performing a link the ansi c compiler will invoke
the 32-bit linker. CFLAGS or LDFLAGS (preferably the later)
really should be sent in with the link.

Also, the ruby build on HPUX falsy detects several other
libraries. Here is some perl in my little build script
that, after the configure, removes these false lib
dependencies. Note, that the problem you gave me a
patch for cannot be fixed in this manner because the Makefile
with the problem is not generated until runtime, and we
could not figure out where we needed to jump in and
change the meta-build infrastructure.

Here's the perl:
perl -pe 's/\-ltinfo//g ; s/\-lsocket/-lnsl/g ; s/\-lsun//g ; s/\-lutil//g
; s/\-DHAVE_OPENPTY//g' -i.bak `find . -name Makefile`
### This points to more bad configure checks? Note, on HPUX the symbols found
lin -lsocket are really found in -lnsl.

perl -pe 's/have_library\("tinfo", "tgetent"\) or have_library\("termcap",
"tgetent"\)//g' -i ext/curses/extconf.rb
### We couldn't find these libs on HPUX. They don't seem to be in ncurses.
perl -pe 's/have_library\("sun", "getpwnam"\)//g' -i ext/etc/extconf.rb
### Not sure what is firing -lsun in configure.
perl -pe 's/have_library\("socket", "socket"\)/have_library("nsl",
"socket")/g' -i ext/openssl/extconf.rb
### -lsocket -> -lnsl

Any sort of patching you can do to make this build go more
smoothly on HPUX is greatly appreciated. I'm very thankful
for the patch you gave me so far. I'm very happy to test
anything out you'd like me to test. Since you've fixed one
problem I figured I'd report the rest that we found. I think
this covers all of the HP-UX and non-hpux issues that we found.

-Rob



Hi,

At Wed, 1 Sep 2004 05:55:10 +0900,
nesius wrote in [ruby-talk:111144]:
The test is:
$CC -o conftest $CFLAGS -lutil -E conftest.c

-E tells both gcc and ansic to dump the pre-processor output.
gcc interprets -o as a directive to dump the output into conftest.
/opt/ansic/bin/cc, when it sees -E, does not understand -o.
it just dumps the output to stdout. A better way to do this
when using ansic is to use the '-P' directive, like so:
$CC $CFLAGS -P conftest.c. The preprocessor output will
be put into conftest.i.

Thank you, I got it. RUBY_CPPOUTFILE in configure.in seems not
to be working.

Try this patch with deleting config.cache file.


Index: configure.in
===================================================================
RCS file: /cvs/ruby/src/ruby/configure.in,v
retrieving revision 1.245
diff -u -2 -p -r1.245 configure.in
--- configure.in 30 Aug 2004 06:16:29 -0000 1.245
+++ configure.in 1 Sep 2004 01:31:31 -0000
@@ -23,4 +23,5 @@ AC_DEFUN(RUBY_CPPOUTFILE,
CPPFLAGS='-o conftest.i'
AC_TRY_CPP([], rb_cv_cppoutfile=yes, rb_cv_cppoutfile=no)
+test -f conftest.i || rb_cv_cppoutfile=no
CPPFLAGS=$cppflags
rm -f conftest*])
 
N

nesius

Whoops. Please change this line:
performs its link with CFLAGS or LDFLAGS, I have to do To:
performs its link without CFLAGS or LDFLAGS, I have to do
^^^^^^^

-Rob

Thanks, I will try that out.

There are some other problems with the ruby build you should
know about.

First off, the link is not given CFLAGS or LDFLAGS, so I
must set CC to not only define the compiler, but define
all of the other flags I need during the link. I need
to pass in mainly directives to find shared libraries
because my shared libraries do not exist in paths that
exist in ldso.conf.

So, because my libraries are not found by the system, and ruby
performs its link with CFLAGS or LDFLAGS, I have to do
something ugly like this:

-----
# This one rejects CFLAGS and LDFLAGS during link, and links with CC
# So, I'm putting CFLAGS into CC
export CC="$CC $CFLAGS"
-----

This also causes problems when trying to build a 64-bit ruby on
HPUX 11.00 because if +DA2.0W is not seen on the command line
when performing a link the ansi c compiler will invoke
the 32-bit linker. CFLAGS or LDFLAGS (preferably the later)
really should be sent in with the link.

Also, the ruby build on HPUX falsy detects several other
libraries. Here is some perl in my little build script
that, after the configure, removes these false lib
dependencies. Note, that the problem you gave me a
patch for cannot be fixed in this manner because the Makefile
with the problem is not generated until runtime, and we
could not figure out where we needed to jump in and
change the meta-build infrastructure.

Here's the perl:
perl -pe 's/\-ltinfo//g ; s/\-lsocket/-lnsl/g ; s/\-lsun//g ; s/\-lutil//g
; s/\-DHAVE_OPENPTY//g' -i.bak `find . -name Makefile`
### This points to more bad configure checks? Note, on HPUX the symbols found
lin -lsocket are really found in -lnsl.

perl -pe 's/have_library\("tinfo", "tgetent"\) or have_library\("termcap",
"tgetent"\)//g' -i ext/curses/extconf.rb
### We couldn't find these libs on HPUX. They don't seem to be in ncurses.
perl -pe 's/have_library\("sun", "getpwnam"\)//g' -i ext/etc/extconf.rb
### Not sure what is firing -lsun in configure.
perl -pe 's/have_library\("socket", "socket"\)/have_library("nsl",
"socket")/g' -i ext/openssl/extconf.rb
### -lsocket -> -lnsl

Any sort of patching you can do to make this build go more
smoothly on HPUX is greatly appreciated. I'm very thankful
for the patch you gave me so far. I'm very happy to test
anything out you'd like me to test. Since you've fixed one
problem I figured I'd report the rest that we found. I think
this covers all of the HP-UX and non-hpux issues that we found.

-Rob



Hi,

At Wed, 1 Sep 2004 05:55:10 +0900,
nesius wrote in [ruby-talk:111144]:
The test is:
$CC -o conftest $CFLAGS -lutil -E conftest.c

-E tells both gcc and ansic to dump the pre-processor output.
gcc interprets -o as a directive to dump the output into conftest.
/opt/ansic/bin/cc, when it sees -E, does not understand -o.
it just dumps the output to stdout. A better way to do this
when using ansic is to use the '-P' directive, like so:
$CC $CFLAGS -P conftest.c. The preprocessor output will
be put into conftest.i.

Thank you, I got it. RUBY_CPPOUTFILE in configure.in seems not
to be working.

Try this patch with deleting config.cache file.


Index: configure.in
===================================================================
RCS file: /cvs/ruby/src/ruby/configure.in,v
retrieving revision 1.245
diff -u -2 -p -r1.245 configure.in
--- configure.in 30 Aug 2004 06:16:29 -0000 1.245
+++ configure.in 1 Sep 2004 01:31:31 -0000
@@ -23,4 +23,5 @@ AC_DEFUN(RUBY_CPPOUTFILE,
CPPFLAGS='-o conftest.i'
AC_TRY_CPP([], rb_cv_cppoutfile=yes, rb_cv_cppoutfile=no)
+test -f conftest.i || rb_cv_cppoutfile=no
CPPFLAGS=$cppflags
rm -f conftest*])
 
N

nobu.nokada

Hi,

At Wed, 1 Sep 2004 11:37:25 +0900,
nesius wrote in [ruby-talk:111163]:
First off, the link is not given CFLAGS or LDFLAGS, so I
must set CC to not only define the compiler, but define
all of the other flags I need during the link. I need
to pass in mainly directives to find shared libraries
because my shared libraries do not exist in paths that
exist in ldso.conf.

I guess that you can give those flags to latest configure.in.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top