Mail Archives: cygwin-apps/2001/06/11/19:00:28
----- Original Message -----
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
<snip>
> > 1) build-relink.test spits out
> > "shlibpath_overrides_runpath should be set to yes."
> > I'm not sure what that should be for cygwin, so I'm referring the
> > question to the libtool list :]. I'm happy to dig further if the
issue
> > is a bug, but if setting this to yes is the correct action there's
> > little to do :].
>
> This isn't an error message, is it? In any case, I don't think the MS
> runtime linker allows the dll itself or an executable to specify a
shlib
> search path. The runtime linker always follows this search order:
> (a) look in the same directory as the executable which needs the
> shlib.
> (b) search the system $PATH
> Win2K added a new twist, but I forget the details. Something about
> adding a second file in the same directory as the exe (say, foo.exe),
> called 'foo.path' or somesuch. That second file can then specify
where
> the needed dlls should be searched for first. Or something. This was
> discussed on the cygwin-apps mailing list...go check that for the real
> details. In any case, this second file is a *second* file == the exe
> *itself* can't override the default shlib search path.
>
> So, I think this should be "no" on cygwin (and mingw, and pw32...)
I think the shlib_overrides_runpath means the LDPATH on unix systems,
and PATH on win32 systems, overriding the -rpath compiled in path. In
which case it should be yes on win32, because AFAIK the compiled in path
is ignored :].
<SNIP>
> Just to make sure:
> current cygwin ld, --disable-auto-image-base is the default
> Paul's modified ld, --ENABLE-auto-image-base is the default
> Your modified ld, --disable-auto-image-base is the default
> Right? If so, then I agree with your decision to keep that out of the
> current discussion. That change is orthogonal to the auto-imports
> stuff.
Yes.
> > > (the failures are: quote.test is failing, "error on mkdir .libs"
but I
> > > think thats because cygwin returns an error when you mkdir an
existing
> > > directory - does unix return an error for that?
>
> Yes. (at least, bash somehow realizes that an error occurs, and
prints
> the error message. I assume that is because the mkdir() kernel call
> *itself* reports ESOMETHING.) On Linux-2.4:
>
> [cwilson AT polgara cwilson]$ mkdir evolution
> mkdir: cannot create directory `evolution': File exists
Ok, so for the purposes of the ld and auto-import stuff we can ignore
the quote.test failure.
> > > I have one change that definately isn't a proper solution - and
thats
> > > the extra_LIBS thing I asked about on the list a few days ago. The
> > .dll
> > > needs to go in the search path, or the test script needs to add
the
> > > libs/extra dir to the normal path when the test is run on cygwin,
for
> > a
> > > proper solution.
>
> Hmm...is this for the "link directly to the dll without using an
import
> lib; instead generate a virtual implib on-the-fly" behavior? Why is
> this necessary? Can't you just use an implib? I'm not sure of the
> context, here; please elaborate...
The libtool depdemo test, has an automake recipe like
extradir = $(libdir)/extra
extra_LTLIBRARIES = libl3.la
Which currently installs the library in $prefix/libs/extra, which isn't
in any search path and thus fails the exec test. I've modified the
recipe to install into libs for the purposes of testing what we are
discussing. Options to solve this are also orthogonal to the auto-import
discussion.
Rob
- Raw text -