#312: disable static on win32 if shared
----------------------+-----------------------------------------------------
 Reporter:  rurban    |       Owner:  rurban  
     Type:  bug       |      Status:  assigned
 Priority:  critical  |   Milestone:  1.0     
Component:  none      |     Version:  trunk   
 Severity:  medium    |    Keywords:          
     Lang:            |       Patch:  new     
 Platform:  win32     |  
----------------------+-----------------------------------------------------
Changes (by rurban):

  * status:  new => assigned


Old description:

> Having a static and shared libparrot together will lead to unnecessary
> and very hard to detect conflicts, esp. when being installed together
> later in the same directory.
>
> On building we seperated them so far into build_dir and blib_dir, but
> when I moved it together to test make install it lead to TT #276, when
> parrot picked up the static lib, but the dynamic dynpmc and dynoplibs did
> not initialize the charset.
>
> So my proposal is:
>
> * disable static on win32 per default, (check if shared, and disable
> static then)[BR]]
>   * or rename it to something unique (libparrots.lib)[BR]]
>   * or move it to blib/lib but set blib_dir to . (the current patch I
> posted)[BR]]
>     Unless --enable-static is requested, embedders or single file
> solutions might want it.[BR]]
> * provide --enable-static or --disable-shared Configure.pl options
>
> Details how it worked before:
>
> -W,lblib/lib -lparrot uses the libpath search to find
> blib/lib/libparrot.lib (the importlib) which finds libparrot.dll (same
> path as exe).[[BR]]
> The dll must reside near the exe unless rpath enabled unices, otherwise
> we would need a SHRPENV=blib/lib:$PATH macro on every exe invocation
> during all makefiles. alison didn't like that (perl5 uses that approach),
> so I moved the dll to the build_dir and everything is fine, even with
> already installed libparrot.dll.
>
> But libparrot.lib (or .a) the static lib is also there and will confuse
> the libpath search when being installed, because then we have a conflict,
> because the static lib will be found before the importlib, esp. on
> installed packages.
>
> So I switched locations, moved the static lib to blib/lib and removed the
> blibdir from the linker libpath (effectively ignoring it). That's when
> TT#276 appeared.

New description:

 Having a static and shared libparrot together will lead to unnecessary and
 very hard to detect conflicts, esp. when being installed together later in
 the same directory.

 On building we seperated them so far into build_dir and blib_dir, but when
 I moved it together to test make install it lead to TT #276, when parrot
 picked up the static lib, but the dynamic dynpmc and dynoplibs did not
 initialize the charset.

 So my proposal is:

   * disable static on win32 per default, (check if shared, and disable
 static then)[[BR]]
     * or rename it to something unique (libparrots.lib)[[BR]]
     * or move it to blib/lib but set blib_dir to . (the current patch I
 posted)[[BR]]
     Unless --enable-static is requested, embedders or single file
 solutions might want it.[[BR]]
   * provide --enable-static or --disable-shared Configure.pl options

 Details how it worked before:

 -W,lblib/lib -lparrot uses the libpath search to find
 blib/lib/libparrot.lib (the importlib) which finds libparrot.dll (same
 path as exe).[[BR]]
 The dll must reside near the exe unless rpath enabled unices, otherwise we
 would need a SHRPENV=blib/lib:$PATH macro on every exe invocation in all
 makefiles. allison didn't like that (perl5 uses that approach), so I moved
 the dll to the build_dir and everything is fine, even with already
 installed libparrot.dll. Even with make test. Even with already installed
 shared libparrot.

 But libparrot.lib (or .a) the static lib is also there and will confuse
 the libpath search when being installed, because then we have a conflict,
 because the static lib will be found before the importlib, esp. on
 installed packages.

 So I switched locations, moved the static lib to blib/lib and removed the
 blibdir from the linker libpath (effectively ignoring it). That's when
 TT#276 appeared.

--

-- 
Ticket URL: <https://trac.parrot.org/parrot/ticket/312#comment:1>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets

Reply via email to