Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sourceware.cygnus.com Delivered-To: mailing list cygwin@sourceware.cygnus.com From: Steve Jorgensen Message-Id: <199910290048.SAA12002@benson> Subject: Re: DLL creation problem To: dj@delorie.com (DJ Delorie) Date: Thu, 28 Oct 1999 18:48:53 -0600 (MDT) Cc: steve@khoral.com, cygwin@sourceware.cygnus.com In-Reply-To: <199910282355.TAA27706@envy.delorie.com> from "DJ Delorie" at Oct 28, 99 07:55:55 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text DJ Delorie wrote >> > char **envp = environ; >> >> When you have a variable in a DLL, the dll exports the *address* of >> the variable, not the variable itself. Not a problem with functions; >> they're addresses anyway. But, with a data item, it's a little funny. >> Cygwin handles this by telling gcc that the data item is imported from >> a dll, and gcc automagically adds the pointer dereferencing code. >> Thus, a simple assignment might turn into a dereference when compiled. So how do I make the above assignment (or any global variable assignemnt) work as expected? Steve -- ----------------------------------------------------------- Steven Jorgensen steve@khoral.com steve@haunt.com ------------------------------+---------------------------- Khoral Research Inc. | PHONE: (505) 837-6500 6200 Uptown Blvd, Suite 200 | FAX: (505) 881-3842 Albuquerque, NM 87110 | URL: http://www.khoral.com/ ----------------------------------------------------------- -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com