X-Spam-Check-By: sourceware.org Message-ID: <46728D53.972514F3@dessent.net> Date: Fri, 15 Jun 2007 06:00:04 -0700 From: Brian Dessent X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: gcc with glib References: <467155CA DOT 51269500 AT dessent DOT net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com PRIEUR Christophe RD-TECH-ISS wrote: > Okay! You're right, it works. I guess some versions of gcc are a bit > more open-minded on this issue (trying to save my self-esteem of old C > programmer). It has nothing to do with gcc. It's a property of the linker (ld) which is a separate external program, and this behavior is as old as unix, i.e. it's been this way forever. What you might have been trying to say is that on some ELF systems such as Linux or Solaris the order doesn't matter, but this is true only when linking with shared libraries. The order must still be correct even on these systems when linking with static archives. Try the following on Linux: $ echo "int foo (void) { return 42; }" > foo.c && \ cc -c foo.c -o foo.o && \ ar rcs libfoo.a foo.o && \ echo 'extern int foo (void); int main (int c, char **v) { return foo (); }' > main.c && \ cc -c main.c -o main.o && \ cc -L. -lfoo main.o -o main main.o: In function `main': main.c:(.text+0x1d): undefined reference to `foo' collect2: ld returned 1 exit status $ cc main.o -L. -lfoo -o main && ./main ; echo $? 42 Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/