List Info

Thread: ia64 and gcc problem with the option of dynamic-linker
ia64 and gcc problem with the option of dynamic-linker
user name
 2006-02-14 02:46:50 

  


  

           Could u please give me some directions? I
encounter a problem on ia64. For example: there is program hello.c


#include <stdio.h>


int 


main() {


   printf(&quot;hello, world\n&quot;);


&nbsp;  return 0;


}


and another program myld.c, then compile myld.c&nbsp; with gcc and option static


#include <stdio.h>


int


main(){


 &nbsp; printf(&quot;myld\n&quot;);


&nbsp;  return 0;


}&nbsp; &nbsp; &nbsp;  



Then when compiling hello.c with gcc, I use the dynamic-linker option to point to myld.so(complied from myld.c), 


On i386 or x86_64 platform, when executing hello, it will output "myld", which is OK;
but on ia64, it will hang up in executing, would u please tell me y?
Thank u very much.

  

  
  
   
     
    

  

    ia64 and gcc problem with the option of
dynamic-linker
  


  

     user name

     2006-02-14 19:41:27
  


  

    
On Mon, 2006-02-13 at 18:46, William wrote:
> On i386 or x86_64 platform, when executing hello, it
will output
> "myld", which is OK; but on ia64, it will
hang up in executing, would
> u please tell me y? Thank u very much.

I just tried this on a debian unstable system, and it seemed
to work.
    % gcc -static myld.c -o myld.so
    % gcc hello.c -Wl,--dynamic-linker,myld.so
    % ./a.out
    myld
You may need to give more info about what exactly you did,
and on what
system, e.g. what OS, what gcc version, what binutils
(linker) version,
what your exact gcc command lines were, etc.


_______________________________________________
ia64-list mailing list
ia64-listredhat.com
htt
ps://www.redhat.com/mailman/listinfo/ia64-list


  


  

    
  

  
  
   
     
    

  

    ia64 and gcc problem with the option of
dynamic-linker
  


  

     user name

     2006-02-15 06:27:10
  


  

    

  


  

    Thank u for ur answering. But It seems that I cannot manage to do that
yet. My compiling command is the same as yours. But no output, just
hang up. The following is some system information and ld script:


[hedianrxi600-12 liblpg_test]$ cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant)
[hedianrxi600-12 liblpg_test]$ gcc --version
gcc (GCC) 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
Copyright (C) 2004 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[rootrxi600-12 ~]# uname -a
Linux rxi600-12 2.6.9-5.0.3.EL
 #1 SMP Wed Sep 14 22:53:17 JST 2005 ia64 ia64 ia64 GNU/Linux
[rootrxi600-12 test]# cat /proc/cpuinfo
processor  : 0
vendor     : GenuineIntel
arch       : IA-64
family     : Itanium 2
model      : 1

revision   : 5
archrev    : 0
features   : branchlong
cpu number : 0
cpu regs   : 4
cpu MHz    : 1495.939995
itc MHz    : 1495.939995
BogoMIPS   : 2239.75

processor  : 1
vendor     : GenuineIntel

arch       : IA-64
family     : Itanium 2
model      : 1
revision   : 5
archrev    : 0
features   : branchlong
cpu number : 0
cpu regs   : 4
cpu MHz    : 1495.939995
itc MHz    : 1495.939995

BogoMIPS   : 2239.75

and ld script:
GNU ld version 2.15.92.0.2 20040927
  Supported emulations:
   elf64_ia64
   elf_i386
   i386linux
using internal linker script:
==================================================

/* Script for -z combreloc: combine and sort reloc sections */
OUTPUT_FORMAT(&quot;elf64-ia64-little&quot;, "elf64-ia64-little",
	      "elf64-ia64-little")
OUTPUT_ARCH(ia64)
ENTRY(_start)

SEARCH_DIR(&quot;/usr/ia64-redhat-linux/lib&quot;); SEARCH_DIR("/usr/local/lib&quot;); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
/* Do we need any of these for elf?
   __DYNAMIC = 0;    */

SECTIONS
{
  /* Read-only sections, merged into text segment: */
  PROVIDE (__executable_start = 0x4000000000000000); . = 0x4000000000000000 + SIZEOF_HEADERS;
  .interp         : { *(.interp) }
  .hash           : { *(.hash) }

  .dynsym         : { *(.dynsym) }
  .dynstr         : { *(.dynstr) }
  .gnu.version    : { *(.gnu.version) }
  .gnu.version_d  : { *(.gnu.version_d) }
  .gnu.version_r  : { *(.gnu.version_r) }
  .rel.dyn        :

    {
      *(.rel.init)
      *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*)
      *(.rel.fini)
      *(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*)
      *(.rel.data.rel.ro*)
      *(.rel.data .rel.data.* .rel.gnu.linkonce.d.*)

      *(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*)
      *(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*)
      *(.rel.ctors)
      *(.rel.dtors)
      *(.rel.got)
      *(.rel.sdata .rel.sdata.* .rel.gnu.linkonce.s.*)

      *(.rel.sbss .rel.sbss.* .rel.gnu.linkonce.sb.*)
      *(.rel.sdata2 .rel.sdata2.* .rel.gnu.linkonce.s2.*)
      *(.rel.sbss2 .rel.sbss2.* .rel.gnu.linkonce.sb2.*)
      *(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*)

    }
  .rela.dyn       :
    {
      *(.rela.init)
      *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
      *(.rela.fini)
      *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
      *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)

      *(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
      *(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
      *(.rela.ctors)
      *(.rela.dtors)
      *(.rela.got)
      *(.rela.sdata .rela.sdata.* .rela.gnu.linkonce.s.*)

      *(.rela.sbss .rela.sbss.* .rela.gnu.linkonce.sb.*)
      *(.rela.sdata2 .rela.sdata2.* .rela.gnu.linkonce.s2.*)
      *(.rela.sbss2 .rela.sbss2.* .rela.gnu.linkonce.sb2.*)
      *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)

    }
  .rel.plt        : { *(.rel.plt) }
  .rela.plt       : { *(.rela.plt) }
  .rela.IA_64.pltoff   : { *(.rela.IA_64.pltoff) }
  .init           :
  {
    KEEP (*(.init))
  } =0x00300000010070000002000001000400

  .plt            : { *(.plt) }
  .text           :
  {
    *(.text .stub .text.* .gnu.linkonce.t.*)
    KEEP (*(.text.*personality*))
    /* .gnu.warning sections are handled specially by elf32.em.  */

    *(.gnu.warning)
  } =0x00300000010070000002000001000400
  .fini           :
  {
    KEEP (*(.fini))
  } =0x00300000010070000002000001000400
  PROVIDE (__etext = .);
  PROVIDE (_etext = .);

  PROVIDE (etext = .);
  .rodata         : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
  .rodata1        : { *(.rodata1) }
  .sdata2         : { *(.sdata2 .sdata2.* .gnu.linkonce.s2.*) }
  .sbss2          : { *(.sbss2 .sbss2.* .gnu.linkonce.sb2.*) }

  .opd            : { *(.opd) }
  .IA_64.unwind_info   : { *(.IA_64.unwind_info* .gnu.linkonce.ia64unwi.*) }
  .IA_64.unwind   : { *(.IA_64.unwind* .gnu.linkonce.ia64unw.*) }
  .eh_frame_hdr : { *(.eh_frame_hdr) }

  .eh_frame       : ONLY_IF_RO { KEEP (*(.eh_frame)) }
  .gcc_except_table   : ONLY_IF_RO { KEEP (*(.gcc_except_table)) *(.gcc_except_table.*) }
  /* Adjust the address for the data segment.  We want to adjust up to

     the same address within the page on the next page up.  */
  . = 0x6000000000000000 + (. & (0x10000 - 1));
  /* Exception handling  */
  .eh_frame       : ONLY_IF_RW { KEEP (*(.eh_frame)) }
  .gcc_except_table   : ONLY_IF_RW { KEEP (*(.gcc_except_table)) *(.gcc_except_table.*) }

  /* Thread Local Storage sections  */
  .tdata	  : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
  .tbss		  : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
  /* Ensure the __preinit_array_start label is properly aligned.  We

     could instead move the label definition inside the section, but
     the linker would then create the section even if it turns out to
     be empty, which isn't pretty.  */
  . = ALIGN(64 / 8);
  PROVIDE (__preinit_array_start = .);

  .preinit_array     : { KEEP (*(.preinit_array)) }
  PROVIDE (__preinit_array_end = .);
  PROVIDE (__init_array_start = .);
  .init_array     : { KEEP (*(.init_array)) }
  PROVIDE (__init_array_end = .);

  PROVIDE (__fini_array_start = .);
  .fini_array     : { KEEP (*(.fini_array)) }
  PROVIDE (__fini_array_end = .);
  .ctors          :
  {
    /* gcc uses crtbegin.o to find the start of
       the constructors, so we make sure it is

       first.  Because this is a wildcard, it
       doesn't matter if the user does not
       actually link against crtbegin.o; the
       linker won't look for a file to match a
       wildcard.  The wildcard also means that it

       doesn't matter which directory crtbegin.o
       is in.  */
    KEEP (*crtbegin*.o(.ctors))
    /* We don't want to include the .ctor section from
       from the crtend.o file until after the sorted ctors.

       The .ctor section from the crtend file contains the
       end of ctors marker and it must be last */
    KEEP (*(EXCLUDE_FILE (*crtend*.o ) .ctors))
    KEEP (*(SORT(.ctors.*)))
    KEEP (*(.ctors))

  }
  .dtors          :
  {
    KEEP (*crtbegin*.o(.dtors))
    KEEP (*(EXCLUDE_FILE (*crtend*.o ) .dtors))
    KEEP (*(SORT(.dtors.*)))
    KEEP (*(.dtors))
  }
  .jcr            : { KEEP (*(.jcr)) }

  .data.rel.ro : { *(.data.rel.ro.local) *(.data.rel.ro*) }
  .dynamic        : { *(.dynamic) }
  .data           :
  {
    *(.data .data.* .gnu.linkonce.d.*)
    KEEP (*(.gnu.linkonce.d.*personality*))

    SORT(CONSTRUCTORS)
  }
  .data1          : { *(.data1) }
  .got            : { *(.got.plt) *(.got) }
  .IA_64.pltoff   : { *(.IA_64.pltoff) }
  /* We want the small data sections together, so single-instruction offsets

     can access them all, and initialized data all before uninitialized, so
     we can shorten the on-disk segment size.  */
  .sdata          :
  {
    *(.sdata .sdata.* .gnu.linkonce.s.*)
  }
  _edata = .;

  PROVIDE (edata = .);
  __bss_start = .;
  .sbss           :
  {
    PROVIDE (__sbss_start = .);
    PROVIDE (___sbss_start = .);
    *(.dynsbss)
    *(.sbss .sbss.* .gnu.linkonce.sb.*)
    *(.scommon)

    PROVIDE (__sbss_end = .);
    PROVIDE (___sbss_end = .);
  }
  .bss            :
  {
   *(.dynbss)
   *(.bss .bss.* .gnu.linkonce.b.*)
   *(COMMON)
   /* Align here to ensure that the .bss section occupies space up to

      _end.  Align after .bss to ensure correct alignment even if the
      .bss section disappears because there are no input sections.  */
   . = ALIGN(64 / 8);
  }
  . = ALIGN(64 / 8);
  _end = .;

  PROVIDE (end = .);
  /* Stabs debugging sections.  */
  .stab          0 : { *(.stab) }
  .stabstr       0 : { *(.stabstr) }
  .stab.excl     0 : { *(.stab.excl) }
  .stab.exclstr  0 : { *(.stab.exclstr) }

  .stab.index    0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment       0 : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning

     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug          0 : { *(.debug) }
  .line           0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo  0 : { *(.debug_srcinfo) }

  .debug_sfnames  0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges  0 : { *(.debug_aranges) }
  .debug_pubnames 0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info     0 : { *(.debug_info .gnu.linkonce.wi.*) }

  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }

  .debug_macinfo  0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }

  .debug_varnames  0 : { *(.debug_varnames) }
  /DISCARD/ : { *(.note.GNU-stack) }
}



14 Feb 2006 11:41:27 -0800, James E Wilson <tuliptree.org">wilsontuliptree.org>:

On Mon, 2006-02-13 at 18:46, William wrote:
>; On i386 or x86_64 platform, when executing hello, it will output
>; "myld", which is OK; but on ia64, it will hang up in executing, would
> u please tell me y? Thank u very much.


I just tried this on a debian unstable system, and it seemed to work.
&nbsp; &nbsp; % gcc -static myld.c -o myld.so
&nbsp; &nbsp; % gcc hello.c -Wl,--dynamic-linker,myld.so
&nbsp; &nbsp; % ./a.out
&nbsp; &nbsp; myld
You may need to give more info about what exactly you did, and on what

system, e.g. what OS, what gcc version, what binutils (linker) version,
what your exact gcc command lines were, etc.


_______________________________________________
ia64-list mailing list
redhat.com">
ia64-listredhat.com
https://www.redhat.com/mailman/listinfo/ia64-list



  

  
  
   
     
    

  

    ia64 and gcc problem with the option of
dynamic-linker
  


  

     user name

     2006-02-15 20:41:58
  


  

    
On Tue, 2006-02-14 at 22:27, William wrote:
> Red Hat Enterprise Linux AS release 4 (Nahant)

I don't have a copy of RHEL4 unfortunately.  That costs
money.  It is a
recent enough OS though that I would expect everything to
work OK.

On my debian system, I have gcc-4.0.2, binutils-2.16.1,
glibc-2.3.5.

Not much I can do to help you further as I can't reproduce
it.  Also, I
don't know much about how glibc internals work.  I would
guess this is a
glibc issue, with how glibc is loading and running the
dynamic linker.
You could maybe try asking on a glibc list.


_______________________________________________
ia64-list mailing list
ia64-listredhat.com
htt
ps://www.redhat.com/mailman/listinfo/ia64-list


  


  

    
  

  
  
   
     
    






 [1-4]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )