Jonathan Worthington wrote:
"Greg Bacon" <[EMAIL PROTECTED]> wrote:
I'm still seeing a link failure with r11221.
Discovered I have cygwin on this PC, went to investigate
and...<hackery happens>...the link failure is gone as well as the
auto-import warnings. Sadly, there's a new problem that I really have
no idea about (aside from the fact that the DLL doesn't get created in
the right place, but that can be fixed easily enough). When you run
miniparrot.exe, it immediately segfaults. Please can someone verify
this isn't just me having a dodgy cygwin setup?
There certainly seem to be a few recent events which can now trigger a
newish problem:
* The default build prefix has become /usr/local
* More people are now doing a 'make install'
* The parrot interfaces have changed in the last few weeks
* Quite a few Perl builds seems to have -L/usr/local/lib included in
their 'lddlflags'
These 4 factors seem to be mean that libparrot will sometimes reside in
/usr/local/lib, a -L/usr/local/lib is added to the link line quite early
on (e.g. with LINKFLAGS), and the problem manifests itself because the
API has changed so that linking or perhaps running parrot breaks.
The real problem is that -L/usr/local/lib is brought in from parrot, so
we have a few choices:
* Just remove -Ls brought in from 'lddflags', which seems safe to me, or
* remove the -L and add it to another config var, or
* rearrange the flags in root.in so that LINKFLAGS is after
ALL_PARROT_LIBS
Does anyone have a strong preference?
Nick
p.s. I saw a followup from Greg that he didn't have libparrot in
/usr/local/lib, but this is certainly a problem that I'm seeing
p.p.s. On cygwin, being Windows, DLLs are searched for in the path, you
need to run 'PATH=$PATH:$PWD/blib/lib' (assuming you are in the parrot
build directory). If things run without this line (or segfault) then
you're picking up the wrong DLL.
