From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Lance Taylor To: joel@merlin.gcs.redstone.army.mil Cc: gas2@cygnus.com Subject: Re: binutils 2.7 mipsorion64-elf question Date: Wed, 11 Sep 1996 11:25:00 -0000 Message-id: <199609111825.OAA23702@sanguine.cygnus.com> References: X-SW-Source: 1996/msg00107.html Date: Wed, 11 Sep 1996 13:11:43 -0500 (CDT) From: "Joel Sherrill " I am trying to verify that the newly submitted mips port of rtems compiles and was merged correctly and may have tripped across a problem: The submitter was using the very old "cygnus-2.6.4-950101" whatever that is. I am using binutils 2.7 and gcc 2.7.2 snapshot 960719 configured for mips64orion-rtems which is a clone of mips64orion-elf. The warning from ld is: liblnk.rel: uses different e_flags (0x0) fields than previous modules (0x20000001) clock.rel: uses different e_flags (0x1) fields than previous modules (0x20000001) I can't explain the reason why sometimes it is a 0x0 and sometimes it is a 0x1 but I think that all of the files with this problem were generated using "ld -r". Does this sound like a known/familiar problem or do you need some more information from me? This is a known problem. The 2.7 linker warns if you try to link object files that look like they were compiled for different ISA levels. Unfortunately, the 2.7 ld -r always generates object files that look like they were compiled for ISA level 0. So, when you link ld -r output with -mips3 output, you get a warning. The bug in ld -r is fixed in the current snapshots, and will be fixed in the 2.8 release. The different between 0x0 and 0x1 is ignored (I hope). A 0x1 just means that .set noreorder was used in the source. Ian