Andy, I totally agree, and this still works. We would then get a compile line like:
gcc ... -L.../blib/lib -lparrot -L/usr/local/lib -lgmp -lreadline So that libparrot is found in blib/lib, and the other libraries in /usr/local/lib. What's evil with some builds of perl is that -L/usr/local/lib is added to to the link flags so that you get: gcc ... -L/usr/local/lib ... -L.../blib/lib -lparrot -L/usr/local/lib -lgmp -lreadline which now finds libparrot system-wide, and causes various breakages depending on how old it is. (I'm by no means an expert on this, but given quite a bit of thought to the problem. My solution is either to remove -L's which Perl supplies, or move them later in the link line) Nick On 27/03/06, Andrew Dougherty <[EMAIL PROTECTED]> wrote: > On Mon, 27 Mar 2006, Nick Glencross wrote: > > > On 26/03/06, Sean Sieger <[EMAIL PROTECTED]> wrote: > > > On 3/25/06, Nick Glencross <[EMAIL PROTECTED]> wrote: > > > > > > > Is it possible that a 'make install' has previously been done on this > > > > computer, so that there is a libparrot in /usr/local/lib? > > > > > > Yep; compiling now. > > > > Great. The problem is caused because Configure extracts compile flags > > from Perl, and on some distributions Perl specifies -L/usr/local/lib > > as a linker flag, which has the potential to pick up a bogus old > > parrot library if it has been previously installed. > > But specifying -L/usr/local/lib is a perfectly reasonable thing to want to > do, especially if parrot is to be linked with some other library in > /usr/local/lib. Off the top of my head, -lgmp, -lgdbm, and -lreadline are > three examples of libraries that Configure already goes looking for that > might reasonably be looked for in /usr/local/lib. > > -- > Andy Dougherty [EMAIL PROTECTED] >
