Thread: /usr/local/{include,lib} on Cygwin
Our build system is set up to automatically include -I/usr/local/include and -L/usr/local/lib on the compile and link command lines on Cygwin. Now I see a lot of users where this issues a warning message that this directory doesn't exist. This may confuse new users. Also, shouldn't gcc be searching these directories automatically? Can someone comment whether it would be better to remove these explicit options? -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Tue, Mar 06, 2001 at 05:35:16PM +0100, Peter Eisentraut wrote: > Our build system is set up to automatically include -I/usr/local/include > and -L/usr/local/lib on the compile and link command lines on Cygwin. > Now I see a lot of users where this issues a warning message that this > directory doesn't exist. This may confuse new users. Also, shouldn't gcc > be searching these directories automatically? Can someone comment whether > it would be better to remove these explicit options? gcc uses them automatically: no why they are: cygipc should be there. [binary package installs there] When the user is new it does not have /usr/local, I guess he wont have cygipc too and the build fails anyway (?). Actually configure should search specifically for cygipc and report if not found. Last time I looked it blindly used '-L/usr/local/lib -lcygipc', so if the cygipc was missing it stopped mysterous places like checking whether the C compiler (gcc ) works... no I am ocassionally newbie too... And I had /usr/local. If I hadnt it maybe it would failed somewhere else, dunno, ATM I dont have NT nearby so cant test. -- marko
Peter, On Tue, Mar 06, 2001 at 05:35:16PM +0100, Peter Eisentraut wrote: > Our build system is set up to automatically include -I/usr/local/include > and -L/usr/local/lib on the compile and link command lines on Cygwin. > Now I see a lot of users where this issues a warning message that this > directory doesn't exist. This may confuse new users. Also, shouldn't gcc > be searching these directories automatically? I'm not a gcc expert, but from empirical evidence I was able to determine that Cygwin gcc seems to automatically search /usr/local/include and /usr/local/lib during compilation and linking, respectively. Hence, it seems that the above options are redundant. > Can someone comment whether > it would be better to remove these explicit options? If removing redundancy is better, then I guess so. Nevertheless, I just removed them from src/Makefile.global and src/backend/Makefile, did a make clean, make and a fairly recent CVS source tree built without errors. Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
Jason Tishler <Jason.Tishler@dothill.com> writes:
> I'm not a gcc expert, but from empirical evidence I was able to determine
> that Cygwin gcc seems to automatically search /usr/local/include and
> /usr/local/lib during compilation and linking, respectively.
I believe that the built-in search paths for gcc are a
configuration-time option, with (if hazy memory serves) defaults that
vary across platforms. However, /usr/local/include and .../lib are
certainly in those paths on *most* platforms. If Jason can attest that
they're in there in the standard Cygwin build of gcc, then I see no
reason to fear assuming that they're normally there for cygwin.
More generally, I don't see a reason for our makefiles to assume they
know better than the compiler does what the default paths should be.
regards, tom lane
Tom, On Tue, Mar 06, 2001 at 11:22:34PM -0500, Tom Lane wrote: > Jason Tishler <Jason.Tishler@dothill.com> writes: > > I'm not a gcc expert, but from empirical evidence I was able to determine > > that Cygwin gcc seems to automatically search /usr/local/include and > > /usr/local/lib during compilation and linking, respectively. > > I believe that the built-in search paths for gcc are a > configuration-time option, with (if hazy memory serves) defaults that > vary across platforms. However, /usr/local/include and .../lib are > certainly in those paths on *most* platforms. If Jason can attest that > they're in there in the standard Cygwin build of gcc, then I see no > reason to fear assuming that they're normally there for cygwin. I guess that I spoke too soon or once again I forgot about Cygwin b20.1. I just tried the same experiment on the Cygwin b20.1 gcc. Unfortunately, it does *not* automatically search /usr/local/include during compilation but it *does* automatically search /usr/local/lib during linking. This asymmetry seems strange or at least inconsistent. I've tried 2.95.2-6, 2.95.2-7, and b20.1 and I can't get gcc to explicitly tell me that it will automatically search /usr/local/lib during linking. I am using the -print-search-dirs which displays the follow (for 2.95.2-7): $ gcc -print-search-dirs install: /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/ programs: /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/:/usr/lib/gcc-lib/i686-pc-cygwin/:/usr/lib/gcc/i686-pc-cygwin/2.95.2-7/:/usr/lib/gcc/i686-pc-cygwin/:/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/../../../../i686-pc-cygwin/bin/i686-pc-cygwin/2.95.2-7/:/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/../../../../i686-pc-cygwin/bin/ libraries: /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/:/usr/lib/gcc/i686-pc-cygwin/2.95.2-7/:/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/../../../../i686-pc-cygwin/lib/i686-pc-cygwin/2.95.2-7/:/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/../../../../i686-pc-cygwin/lib/:/usr/lib/i686-pc-cygwin/2.95.2-7/:/usr/lib/:/usr/lib/mingw/i686-pc-cygwin/2.95.2-7/:/usr/lib/mingw/:/lib/i686-pc-cygwin/2.95.2-7/:/lib/:/usr/lib/i686-pc-cygwin/2.95.2-7/:/usr/lib/ Does anyone know how to glean this information from gcc? Should I actually be asking ld? Anyway, if the PostgreSQL teams stills wants to support Cygwin b20.1, then the -I/usr/local/include option should be set for b20.1 during configure. Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
Jason Tishler writes: > Does anyone know how to glean this information from gcc? Should I > actually be asking ld? Giving a -v to gcc will explicitly list search paths and more. > Anyway, if the PostgreSQL teams stills wants to support Cygwin > b20.1, then the -I/usr/local/include option should be set for b20.1 > during configure. I'd still be happy to leave it that we can build on B20.1 but not OOTB. -- Pete Forman -./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent pete.forman@westerngeco.com -./\.- opinion of Schlumberger, Baker http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.
Pete,
On Thu, Mar 08, 2001 at 10:48:00AM +0000, Pete Forman wrote:
> Jason Tishler writes:
> > Does anyone know how to glean this information from gcc? Should I
> > actually be asking ld?
>
> Giving a -v to gcc will explicitly list search paths and more.
Actually, I have been using gcc -v, but its output does not contain
"-L/usr/local/lib". For example,
$ gcc -v -o j j.c -lpth
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/specs
gcc version 2.95.2-7 19991024 (cygwin experimental)
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/cpp.exe -lang-c -v -D__GNUC__=2 -D__GNUC_MINOR__=95 -Di386 -D__386__ -D__i386
-D_X86=1-D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__))
-D__declspec(x)=__attribute__((x))-D__i386__ -D__386__ -D__i386 -D_X86=1 -D__STDC__=1
-D__stdcall=__attribute__((__stdcall__))-D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x))
-D__i386-Asystem(winnt) -Acpu(i386) -Amachine(i386) -remap -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__
-Di686-Dpentiumpro -D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__
-D__unix-isystem /usr/local/include -idirafter /usr/include j.c /mnt/c/TEMP/ccGFCuoi.i
GNU CPP version 2.95.2-7 19991024 (cygwin experimental) (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/include
/usr/include
End of search list.
The following default directories have been omitted from the search path:
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/../../../../include/g++-3
End of omitted list.
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/cc1.exe /mnt/c/TEMP/ccGFCuoi.i -quiet -dumpbase j.c -version -o
/mnt/c/TEMP/ccOkwhdA.s
GNU C version 2.95.2-7 19991024 (cygwin experimental) (i686-pc-cygwin) compiled by GNU C version 2.95.2-7 19991024
(cygwinexperimental).
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/../../../../i686-pc-cygwin/bin/as.exe -o /mnt/c/TEMP/ccSbZyQX.o
/mnt/c/TEMP/ccOkwhdA.s
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7/collect2.exe -Bdynamic -o j.exe /usr/lib/crt0.o
-L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-7-L/usr/lib/mingw /mnt/c/TEMP/ccSbZyQX.o -lpth -lgcc -lcygwin -luser32
-lkernel32-ladvapi32 -lshell32 -lgcc
So from the above, it is clear that Cygwin gcc 2.95.2-7 will search
/usr/local/include for #include files. However, there is no indication
that it will search /usr/local/lib for library files. But, libpth.a is
only located in /usr/local/lib in my system. How does collect2 find it?
I just tried the old faithful, strings:
$ strings /usr/bin/ld.exe | fgrep /usr/local/lib
SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib);
SEARCH_DIR(/usr/i686-pc-cygwin/lib);
SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib);
SEARCH_DIR(/usr/i686-pc-cygwin/lib);
SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib);
SEARCH_DIR(/usr/i686-pc-cygwin/lib);
The above appears to indicate that ld's default library search path is:
/lib:/usr/lib:/usr/local/lib:/usr/i686-pc-cygwin/lib
Is there any way to get ld to tell us this information without resorting
to strings?
Thanks,
Jason
--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com
Jason Tishler writes: > Is there any way to get ld to tell us this information without > resorting to strings? ld --verbose Here's what I get on my two Cygwins. $ uname -r 20.1 (0.3/1/1) $ ld --verbose | grep -E 'version|SEARCH_DIR' GNU ld version 2.9.4 (with BFD 2.9.4) SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/cygnus/cygwin-b20/H-i586-cyg win32/lib); SEARCH_DIR(/usr/local/lib); SEARCH_DIR(/cygnus/cygwin-b20/H-i586-cyg win32/i586-cygwin32/lib); $ uname -r 1.1.4(0.26/3/2) $ ld --verbose | grep -E 'version|SEARCH_DIR' GNU ld version 2.10.91 (with BFD 2.10.91) SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); SEARCH_DIR(/ usr/i686-pc-cygwin/lib); -- Pete Forman -./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent pete.forman@westerngeco.com -./\.- opinion of Schlumberger, Baker http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.
Pete, On Fri, Mar 09, 2001 at 02:04:47PM +0000, Pete Forman wrote: > Jason Tishler writes: > > Is there any way to get ld to tell us this information without > > resorting to strings? > > ld --verbose Ahh! Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com