This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [RFA] Make LIB_PATH configurable
On Thu, Apr 26, 2001 at 10:58:47AM -0700, Ian Lance Taylor wrote:
>Christopher Faylor <cgf@redhat.com> writes:
>
>> >I don't understand why you need to do this in a cross-configuration.
>> >In a cross-configuration you're in complete control of where the
>> >libraries are installed. Why not install all the libraries in the lib
>> >directory?
>>
>> Because the makefile which installs the .a files puts them in a
>> subdirectory. I could, of course, attempt to detect when this is happening
>> in a cross-build environment but that seems sort of pointless. Why
>> not have the cross build mimic the native directory structure if
>> possible?
>
>cygwin is a weird case. But if you suggested that for some other
>operating system, such as Solaris, and said something like ``why not
>mimic the separation of /usr/lib and /usr/ccs/lib in a cross
>environment?'' my only response would be ``you could do that, but why
>bother?''
In that case, you'd be right. We don't control Solaris, and we'd
have to copy the files from a Solaris system into a separate directory
to accomodate this anyway.
In the Cygwin case, Cygwin is part of the build tree. It (currently)
installs files in .../lib and .../lib/w32api.
The problem is that I have to put the logic somewhere. To me, it
makes sense to use the already existing facility in ld to accomodate
this rather than add "if cross-compiling" logic to the Makefile for
cygwin library installation.
>A cross environment is not a native environment. There's no special
>reason for them to use a similar directory structure.
One special reason in this case is to avoid extra logic in another
Makefile. I thought that adding this flexibility to the ld Makefile
made some sense, though. I thought it was sort of odd that the README
instructs people to essentially edit the Makefile if they want to add
additional library search paths to a cross-linker environment. To me,
this is what configure is for.
Actually, I probably should go into the reason for isolating the w32api
stuff from /usr/lib. The reason for the separation is to accomodate
gcc's -mno-cygwin option. This option allows people to compile Windows
binaries that do not rely on Cygwin. When include files or libraries
are intermixed, it often leads to confusion because people specify
-mno-cygwin and still attempt to link with cygwin libraries or use
cygwin-specific include files.
So, I separated the include directories a while ago. That means
that people get a "file not found" error when they attempt to
use a cygwin include file rather than a potentially confusing
link error.
I'm trying to do the same thing with libraries now. Moving windows
specific libraries into their own directory is a step towards isolating
cygwin libraries from non-cygwin libraries. It doesn't provide any real
benefit yet because ld always searches /usr/lib but I'm anticipating a
potential -nostdlib or equivalent patch to ld which would work around
this to allow gcc to suppress ld's searching of /usr/lib.
The patch in question is actually to accomodate dllwrap which calls ld
directly.
cgf