On 12/23/05, Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
>
> Below are my thoughts on this patch in it's current form.
>
> I don't like the function of ld_libparrot_soname because it has the
> soname mixed up with the linker flags. I'd rather see something like
> ld_soflags and libparrot_soname (I don't have strong feelings about the
> names).
I can look at that, but it may not be possible for the next couple of
days...
Building a shared lib and building a static lib shouldn't be an
> either/or operation. I'd like to be able to build and install both
> (assuming your platform supports this) and I think this should be the
> default behavior. That means we probably need some CLI flags like
> '--disable-shared' & '--disable-static' (just like autoconf). Although,
> anything other than '--libparrot_is_shared' would be an improvement.
Ok, let me explain my problem on this, and see if someone can help with the
solutions. If both shared and static libraries exist in blib/lib, then to
link against the static one I believe that I would need:
... -Bstatic -lparrot -Bdynamic ...
but I don't know how portable that is. Is there another way, and how do I do
this portably...?
Another simply alternative is to place the shared/static libraries in
different directories.
There are tabs mixed with whitespace outside of makefiles. I've been
> biting my tongue about this so far but perhaps it's time to start a
> thread this on subject. Anyways, please remove the tabs from your
> patch.
I need to make them more visible in my editor, don't I!... Sorry!
Using ExtUtils::Command for MKDIR is a no brainier but a) I think this
> change is unrelated to main intent of this patch and b) I'd rather that
> ${mkdir} is expanded in root.in instead of setting the command
> explicitly (I know this is done other places in root.in, it needs to be
> cleaned up). I've committed b) as r10633.
Thanks.
I'm also pretty sure that the "rpath" concept won't work on many
> platforms, including OSX. I'd feel a lot better about this patch if it
> was demonstrated to work on OSX. In it's current form it causes link
> errors.
Two comments on this.
I know that rpath isn't portable, but the concept often is. I've used rpath
on Linux, and it's equivalent on HP-UX. It's very much a linker thing,
rather than a compiler one, isn't it.
Secondly, it isn't mandatory to have it working on every platform -- just
nice. You'll see that I've added something at the end of
Configure.pl(better locations accepted) which prints a message telling
the person to use
LD_LIBRARY_PATH or equivalent as an alternative (e.g. it may be necessary to
set the PATH on cygwin). An an alternative, which is what libtool does, is
to wrap up binaries behind a script which sets the LD_LIBRARY_PATH
internally so that users don't see it.
I've now got an OSX system which I will be able to get working when I'm back
from doing the family thing...
Thanks for working on this.
>
I'm trying my best. :-)
Nick
