Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001353graphvizBuild/Installpublic2008-07-11 19:372011-04-28 04:03
ReporterWarren Dodge 
Assigned Togviz 
PrioritynormalSeveritymajorReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOSx86-Irix-2.6OS Version
Summary0001353: -lperl calculation in configure is not right for some perl builds
Description



In configure at line 27111
<CD>
          PERL_ARCHLIB=`$PERL -e 'use Config; print $Config{archlib};'`
          PERL_INCLUDES=-I$PERL_ARCHLIB/CORE
          PERL_LIBS="-L$PERL_ARCHLIB/CORE -lperl"
</CD>



You assume the library name is perl. I have to change th ename when I build perl so I don't
conflict with another package we use.



It seems you should use the Config array and get the "libperl" entry and sed it from libperlxxx.so to perlxxx



Additional Information

[ellson] Perhaps you could provide a patch for this obscure situation?

On my system, the perl lib is in:
<CD>
   /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/libperl.so
</CD>

Why would you rename the library, instead of just creating a local perl version with its own directories?

[warren]
Well patching isn't my expertise but I can give you the code that would
work. It may not be the simplest/cleanest way to do it.

<CD>
PERL_LIB=`$PERL -e 'use Config; $a= $Config{libperl};$a=~s/lib(.+)\.so/$1/; print $a;'`
PERL_LIBS="-L$PERL_ARCHLIB/CORE -l$PERL_LIB"
</CD>

Why rename the lib? First the problem was a few years ago. That is when
I began to uniqify my perl library name. So the exact reason I really
don't remember. It had to do with a vendors product including their own
real old version to support their app. I am guessing when we used our
perl scripts, using a much newer perl, and mixed in library calls into
there application yjrough a perl module things got confused. Probably
the PATH or LD_LIBRARY_PATH could not be set to satisfy both things.

Why build my own perl? We have many users who all have a local
workstation. Managing the perl modules and updates on that many would be
insane. We have a single copy that they nfs mount. This give a single
point of updating for all and makes my life and theirs much nicer.

Also getting the IT department to let us modify the machines is near
impossible. The just don't understand engineers. or maybe they do:>)

[ellson] Sorry, can't use that. Shared libraries do not have a .so extension on all platforms.

You could of course use it as a local patch.
TagsNo tags attached.
AUXILLARY-FILES
DATE-FIXED
FIX-COMMENT
FORMER-ID1387
INPUT-FILE
OUTPUT-FILE
STATUS-COMMENT*
VERSION     2.20.2
Attached Files

- Relationships

-  Notes
There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2011-04-28 04:03 user1 New Issue
2011-04-28 04:03 user1 Assigned To => user1


MantisBT 1.2.5[^]
Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker