This is the mail archive of the email@example.com mailing list for the gas2 project.
|Index Nav:||[Date Index] [Subject Index] [Author Index] [Thread Index]|
|Message Nav:||[Date Prev] [Date Next]||[Thread Prev] [Thread Next]|
Date: Wed, 11 Sep 1996 13:11:43 -0500 (CDT) From: "Joel Sherrill <firstname.lastname@example.org>" <email@example.com> 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