id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc	lang	patch	platform
30	make shared libparrot with an already installed  shared libparrot	rurban	jkeenan	"(migrated from RT 39742)

The reason for the problem to make shared libparrot with an already installed 
shared libparrot is simple and has several reasons:

1. libs belongs to the end. 

first LDFLAGS, then LD_LOAD_FLAGS, then libparrot, 
then LIBS + EXTRALIBS.

dynpmc got this wrong. 
It had LIBS at the front. 
  a. One should not put libs before the LDFLAGS.
  b. One should reverse the LIBS line in order of dependencies.
     We have the problem that the libs line is generated automatically 
     and may contain -L/usr/lib (pulled in from libicu) and -L/usr/local/lib, 
     so the already installed -lparrot will be found. 

So our -Lblib/lib should be at the front, best in LDFLAGS.
Note that parrot.pc got that right:
  Libs: -L${libdir} -lparrot @icu_shared@ @libs@

2. remove the perl5 -L/usr/local/lib LDFLAGS which would pull in 
   a shared /usr/local/lib/libparrot.so before checking -Lblib/lib
  -lparrot.

One fix could be to check this in Configure and move all -L from LDFLAGS
to the LIBS flag at the front. I went this way for unices, and explicitly for win.   
The other fix would be to explicitly link to blib/lib/libparrot.so,
without -L path hacks.

3. Now an already installed libparrot.dll/.so does not conflict with make anymore.
   The remaining problem is at make installable esp. for the languages 
   and already installed /usr/lib/parrot, /usr/include/parrot and
   /usr/lib/libparrot.dll.a

This patch adds PATH resp. LD_RUN_PATH to the parrot invocations, similar as in perl5.
It moves a -L<path> from @ldflags@ to @libs@ in config.
It also adds emacs/vim modes to the Makefiles.
It also adds Makefile targets to regenerate the Makefiles automatically."	todo	closed	normal		configure	branch	medium	fixed		jkeenan		new	linux