FAQ
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/

Search Discussions

  • Marko Kreen at Mar 6, 2001 at 9:47 pm

    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
  • Jason Tishler at Mar 7, 2001 at 4:01 am
    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
  • Tom Lane at Mar 7, 2001 at 4:22 am

    Jason Tishler 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
  • Jason Tishler at Mar 7, 2001 at 6:54 pm
    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
  • Pete Forman at Mar 8, 2001 at 11:30 am

    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.
  • Jason Tishler at Mar 8, 2001 at 2:45 pm
    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 (cygwin experimental).
    /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
  • Pete Forman at Mar 9, 2001 at 2:21 pm

    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.
  • Jason Tishler at Mar 9, 2001 at 2:34 pm
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-ports @
categoriespostgresql
postedMar 6, '01 at 8:47p
activeMar 9, '01 at 2:34p
posts9
users5
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase