problems building perl5.001m on dgux 
Author Message
 problems building perl5.001m on dgux

I actually was able to build perl5.001m on dgux, but not with dynamic
loading which is what I want so that I can build the database modules.  
There were a few things that needed to be worked around even for static,
though.  

1.   Inconsistencies with -lm and -lmalloc
      Configure said it couldn't find them, but
         libm.a and libmalloc.a
      exist in /usr/lib.  So I manually added them to the list of    
      libraries
      to use when Configure asked.  This got us successfully through the
      build of miniperl.  Later, in the build of perl under 'Making    
      POSIX '    we got a message
Warning (non-fatal): No library found for -lm

2.     When checking functions, after strchr() found, it printed:
*** WHOA THERE!!! ***
    The recommended value for $d_index on this machine was "define"!
    Keep the recommended value? [y]

I assumed that y was OK

3.    The problem that's stopping me.  When I try to build dynamic
      miniperl builds fine but when make gets up to  Making DynaLoader
      I get the following warnings:
DynaLoader.c: In function `XS_DynaLoader_dl_load_file':
DynaLoader.c:162: warning: assignment makes pointer from integer without a
DynaLoader.c: In function `XS_DynaLoader_dl_find_symbol':
DynaLoader.c:202: warning: assignment makes pointer from integer without a
       The compilation and a few other things succeed, then I get
Running Mkbootstrap for Fcntl ()
        chmod 644 Fcntl.bs
        LD_RUN_PATH="" gcc -o ../../lib/auto/Fcntl/Fcntl.so  Fcntl.o  
Undefined                       first referenced
 symbol                             in file
main                                /lib/crt0.o
croak                               Fcntl.o
stack_sp                            Fcntl.o
newXS                               Fcntl.o
sv_yes                              Fcntl.o
sv_2iv                              Fcntl.o
na                                  Fcntl.o
sv_2pv                              Fcntl.o
sv_newmortal                        Fcntl.o
stack_base                          Fcntl.o
sv_setnv                            Fcntl.o
markstack_ptr                       Fcntl.o
ld: ../../lib/auto/Fcntl/Fcntl.so: fatal error: Symbol referencing errors.
tput written to ../../lib/auto/Fcntl/Fcntl.so
*** Error code 1

Stop.

I tried serveral variations, but ended up in the same place.  Any help
would be greatly appreciated.

   --Jim Harle



Sat, 11 Jul 1998 03:00:00 GMT  
 problems building perl5.001m on dgux

Quote:

> I actually was able to build perl5.001m on dgux, but not with dynamic
> loading which is what I want so that I can build the database modules.  

You should be able to build a static Perl which includes the database
modules, I'd think, so if the following fails for you you can fall back
to that.

You don't mention which version of dgux you're using.  I've got a hints
file which I've used with 3.10 and it supports dynamic loading.  I just
received 4.11 and reading the release notes I see my hints will need a
little reworking for them to work there.  I'm going to start installing
4.11 next week after which I'll be able to patch the hints up.

The dgux hints file which is included with Perl is a bit out of date.
I've submitted my reworked file so with luck it'll show up in 5.002 or
5.003.  I've tested it with 5.002b2.  I think it will come close to
working with 5.001m but I'm not positive.

Here's a patch which can be loaded on top of the Perl distribution.  It
replaces hints/dgux.sh and applies a small patch to
lib/ExtUtils/Liblist.pm.  See the comments in the hints file for
excruciating detail about what I discovered while working through this
stuff (including the reasons behind the problems you found with the
current dgux.sh).

Index: lib/ExtUtils/Liblist.pm
*** lib/ExtUtils/Liblist.pm     Sun Dec 10 14:41:02 1995
--- ../perl/lib/ExtUtils/Liblist.pm     Thu Jan 25 17:48:01 1996
***************
*** 104,109 ****
--- 104,120 ----
            } elsif (-f ($fullname="$thispth/lib$thislib$Config_libext")){
            } elsif (-f ($fullname="$thispth/$thislib$Config_libext")){
            } elsif (-f ($fullname="$thispth/Slib$thislib$Config_libext")){
+           } elsif ($Config{'osname'} eq 'dgux'
+                && -l ($fullname="$thispth/lib$thislib$Config_libext")
+                && readlink($fullname) =~ /^elink:/) {
+                # Some of DG's libraries look like misconnected symbolic
+                # links, but development tools can follow them.  (They
+                # look like this:
+                #
+                #    libm.a -> elink:${SDE_PATH:-/usr}/sde/\
+                #    ${TARGET_BINARY_INTERFACE:-m88kdgux}/usr/lib/libm.a
+                #
+                # , the compilation tools expand the environment variables.)
            } else {
                print STDOUT "$thislib not found in $thispth\n" if $Verbose;
                next;

Index: hints/dgux.sh
*** hints/dgux.sh       Tue Oct 18 12:32:42 1994
--- ../perl/hints/dgux.sh       Thu Jan 25 17:45:41 1996
***************
*** 1,26 ****
! #
! # hints file for Data General DG/UX
! # these hints tweaked for perl5 on an AViiON mc88100, running DG/UX 5.4R2.01
  #

- gidtype='gid_t'
- groupstype='gid_t'
- libswanted="dgc $libswanted"
- uidtype='uid_t'
- d_index='define'
- ccflags='-D_POSIX_SOURCE -D_DGUX_SOURCE'

! # this hasn't been tried with dynamic loading at all
! usedl='false'

- #
- # an ugly hack, since the Configure test for "gcc -P -" hangs.
- # can't just use 'cppstdin', since our DG has a broken cppstdin :-(
- #
- cppstdin=`cd ..; pwd`/cppstdin
- cpprun=`cd ..; pwd`/cppstdin

! #
! # you don't want to use /usr/ucb/cc
! #
! cc='gcc'
--- 1,123 ----
! # $Id: dgux.sh,v 1.5 1996/01/25 22:45:43 roderick Exp $
!
! # This is a hints file for DGUX, which is Data General's Unix.  It was
! # developed using version 5.4.3.10 of the OS.  I think the gross
! # features should work with versions 2.nil through 4.11.  I know that
! # some minor tweaking will be needed for 4.10 and 4.11 (I just read the
! # release notes), the same is probably true for older versions as well.
! #
! # DGUX is a SVR4 derivative.  It ships with gcc as the standard
! # compiler.  Since version 3.0 it has shipped with Perl 4.036
! # installed in /usr/bin, which is kind of neat.  Be careful when you
! # install that you don't overwrite the system version, though (by
! # answering yes to the question about installing perl as /usr/bin/perl),
! # as it would suck to try to get support if the vendor learned that you
! # were physically replacing the system binaries.
! #
! # Be aware that if you opt to use dynamic loading you'll need to set
! # your $LD_LIBRARY_PATH to include the source directory when you build,
! # test and install the software.
  #

! # Here are the things from some old DGUX hints files which are different
! # from what's in here now.  I don't know the exact reasons that most of
! # these settings were in the hints files, presumably they can be chalked
! # up to old Configure inadequacies and changes in the OS headers and the
! # like.  These settings might make a good place to start looking if you
! # have problems.
! #
! # This was specified the the 4.036 hints file.  That hints file didn't
! # say what version of the OS it was developed using.
! #
! #     cppstdin='/lib/cpp'
! #
! # The 4.036 and 5.001 hints files both contained these.  The 5.001 hints
! # file said it was developed with version 2.01 of DGUX.
! #
! #     gidtype='gid_t'
! #     groupstype='gid_t'
! #     uidtype='uid_t'
! #     d_index='define'
! #     cc='gcc'
! #
! # These were peculiar to the 5.001 hints file.
! #
! #     ccflags='-D_POSIX_SOURCE -D_DGUX_SOURCE'
! #
! #     # an ugly hack, since the Configure test for "gcc -P -" hangs.
! #     # can't just use 'cppstdin', since our DG has a broken cppstdin :-(
! #     cppstdin=`cd ..; pwd`/cppstdin
! #     cpprun=`cd ..; pwd`/cppstdin
! #
! # One last note:  The 5.001 hints file said "you don't want to use
! # /usr/ucb/cc" in the place at which it set cc to gcc.  That in
! # particular baffles me, as I used to have 2.01 loaded and my memory
! # is telling me that even then /usr/ucb was a symlink to /usr/bin.

! # The standard system compiler is gcc, but invoking it as cc changes its
! # behavior.  I have to pick one name or the other so I can get the
! # dynamic loading switches right (they vary depending on this).  I'm
! # picking gcc because there's no way to get at the optimization options
! # and so on when you call it cc.
! case $cc in
!     '')
!       cc=gcc
!       case $optimize in
!           '') optimize=-O2;;
!       esac
!       ;;
! esac
!
! usevfork=true
!
! # DG has this thing set up with symlinks which point to different places
! # depending on environment variables (see elink(5)) and the compiler and
! # related tools use them to access different development environments
! # (COFF, ELF, m88k BCS and so on), see sde(5).  The upshot, however, is
! # that when a normal program tries to access one of these elinks it sees
! # no such file (like stat()ting a mis-directed symlink).  Setting
! # $plibpth to explicitly include the place to which the elinks point
! # allows Configure to find libraries which vary based on the development
! # environment.
! plibpth="$plibpth \
!     ${SDE_PATH:-/usr}/sde/${TARGET_BINARY_INTERFACE:-m88kdgux}/usr/lib"
!
! # Many functions (eg, gethostent(), killpg(), getpriority(), setruid()
! # dbm_*(), and plenty more) are defined in -ldgc.  Usually you don't
! # need to know this (it seems that libdgc.so is searched automatically
! # by ld), but Configure needs to check it otherwise it will report all
! # those functions as missing.
! libswanted="dgc $libswanted"
!
! # Dynamic loading works using the dlopen() functions.  Note that dlfcn.h
! # is broken, it declares _dl*() rather than dl*().  (This is in my
! # I'd-open-a-ticket-about-this-if-it-weren't-going-to-be-such-a-hassle
! # file.)  You can ignore the warnings caused by the missing
! # declarations, they're harmless.
! usedl=true
! # For cc rather than gcc the flags would be `-K PIC' for compiling and
! # -G for loading.  I haven't tested this.
! cccdlflags=-fpic
! lddlflags=-shared
! # The Perl library has to be built as a shared library so that dynamic
! # loading will work (otherwise code loaded with dlopen() won't be able
! # to reference symbols in the main part of perl).  Note that since
! # Configure doesn't normally prompt about $d_shrplib this will cause a
! # `Whoa there!'.  This is normal, just keep the recommended value.  A
! # consequence of all this is that you've got to include the source
! # directory in your LD_LIBRARY_PATH when you're building and testing
! # perl.
! d_shrplib=define
!
! # The system has a function called dg_flock() which is an flock()
! # emulation built using fcntl() locking.  Perl currently comes with an
! # flock() emulation which uses lockf(), it should eventually also
! # include an fcntl() emulation of its own.  Until that happens I
! # recommend using DG's emulation (and ignoring the `WHOA THERE!' this
! # causes), it provides semantics closer to the original than the lockf()
! # emulation.
! ccflags="$ccflags -Dflock=dg_flock"
! d_flock=define

--
Roderick Schertler



Mon, 13 Jul 1998 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. wierd problem building perl5.001m

2. Problems building perl5.001m on VMS

3. DynaLoader problem building perl5.001m on the Crays.

4. perl5.002_01, perl5.003 : dlopen problem under chroot (not in 5.001m)

5. bug in building perl5.001m on AIX

6. Build perl5.001m on IBM 4.1

7. Building perl5.001m on IBM

8. Test Failures Building perl5.001m on Linux

9. Building perl5.001m with SCO OSR5

10. building/testing perl5.001m under Solaris

11. Building tkperl on dgux 3.10

12. Building tkperl on dgux 3.10

 

 
Powered by phpBB® Forum Software