delorie.com/archives/browse.cgi | search |
From: | Alain Magloire <alainm AT rcsm DOT ece DOT mcgill DOT ca> |
Message-Id: | <199905150237.WAA07570@mccoy2.ECE.McGill.CA> |
Subject: | Re: $HOSTNAME doesn't override library code |
To: | djgpp-workers AT delorie DOT com |
Date: | Fri, 14 May 1999 22:37:31 -0400 (EDT) |
In-Reply-To: | <373B3EFD.93C37956@bigfoot.com> from "Richard Dawe" at May 13, 99 10:07:09 pm |
X-Mailer: | ELM [version 2.4 PL25] |
MIME-Version: | 1.0 |
Reply-To: | djgpp-workers AT delorie DOT com |
X-Mailing-List: | djgpp-workers AT delorie DOT com |
X-Unsubscribes-To: | listserv AT delorie DOT com |
Bonjour > > I guess libsocket's lsck_gethostname() should really override > gethostname(). Which order are the libraries linked by gcc? i.e. if I do: > > gcc -o wotsit wotsit.c -lsocket > > does libc get linked before/after libsocket? If the latter is true then I > will make libsocket override libc's gethostname(). > Yes, the linker will try to resolve the symbols from the libraries specify on the command line and then the default ones define in spec. In other words libsocket.a will have precedence. > What is the position on placing network-enabled versions of the relevant > utilities on Simtelnet? I think libsocket's Windows code will soon be > stable enough to make this viable. Until now, I thought it was doing that .i.e libsocket was providing a full BSD Socket API. The real draw back is that it could not work on plain DOS. -- alain
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |