Re: linking weak symbols on interix

Re: linking weak symbols on interix

[Ross Ridge]

Martin Koeppe wrote:
> For libc.a I don't plan to use, i.e. execute, it on linux, e.g. in
>an emulator or wine or so, I only want to link on linux and execute on
>windows. Might this too be not legal?

You'll need to check the licence to find out for sure you have permission
to copy and use Micrsoft runtime library on Linux, even if you're just
linking with it.

						Ross Ridge

Re: linking weak symbols on interix

[Martin Koeppe]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 535 bytes --]


Hi Ross,

> You'll need to check the licence to find out for sure you have 
> permission to copy and use Micrsoft runtime library on Linux, even 
> if you're just linking with it.

here comes the complete eula and the extra copyright and licence of 
some components, in my understanding, these components don't include 
the libc. In my understanding, §2 allows copying and using on linux 
too, or at least doesn't forbid it, as long as you own the hardware.

Thank you for encouraging me to really read the eula.

Martin

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 7389 bytes --]

[-- Attachment #3: Type: APPLICATION/octet-stream, Size: 7329 bytes --]

Re: linking weak symbols on interix

[Martin Koeppe]

Hi Ross,

> The simplest solution may be to use the same source that Microsoft 
> used to build its version of ld.  It should be available from 
> Microsoft.

yes and no. The source is available, in the same archive where the 
interix tools are. However they mixed together a cvs snapshot of 
binutils (pre-2.14) and gcc (pre-3.3) from 2002, then apply several 
patches (these are separate and applied at build time) and changed 
everything so that it can be compiled with their ms c compiler.

I tried to extract the binutils sources and to apply the patches, but 
some of the patches don't apply out of the box and it doesn't build on 
linux as cross config. I didn't try, because it seems not to be easy, 
to rebuild the ms ld natively on interix.

I was happy that gcc 4.1 as cross compiler produces usable .o files, 
so I thought ld could / should be fixed to work, too.

I also tried to build a non-cross ld 2.17 on interix. It builds fine, 
but using it fails with the exactly same issue.


> On the other hand, what you're doing may not be legal.  Microsoft 
> generally doesn't permit their products be used on non-Microsoft 
> operating systems.  While the GPL would permit you to use their ld 
> and libgcc.a on Linux, their EULA may not permit you to use their 
> libc.a.

I only used their libgcc.a to exclude that my cross compiled one from 
gcc 4.1 may have a bug in it. For libc.a I don't plan to use, i.e. 
execute, it on linux, e.g. in an emulator or wine or so, I only want 
to link on linux and execute on windows. Might this too be not legal?

Nevertheless there is a libc.so in interix, and of course I would 
prefer to use that. Don't know if that makes a difference in legality, 
however. Currently I want to produce a somehow working executable 
first.


Martin

Re: linking weak symbols on interix

[Ross Ridge]

Martin Koeppe wrote:
> Any ideas?

The simplest solution may be to use the same source that Microsoft used
to build its version of ld.  It should be available from Microsoft.

On the other hand, what you're doing may not be legal.  Microsoft
generally doesn't permit their products be used on non-Microsoft operating
systems.  While the GPL would permit you to use their ld and libgcc.a
on Linux, their EULA may not permit you to use their libc.a.

					Ross Ridge

linking weak symbols on interix

[Martin Koeppe]

Hi all,

I'm trying to build a working cross linker running on linux and 
linking pe files for interix.

When linking a very simple program with ld 2.17, I get

   $ i586-pc-interix3-ld crt0.o hello.o -L. -lgcc -lc -lpsxdll --print-map
   ./libgcc.a(__main.o): In function `_main':
   /dev/fs/C/gnu2.intel/egcs.source/gcc/libgcc2.c:1885: undefined reference to `atexit'

The beginning of the map is as follows:

   Archive member included because of file (symbol)

   ./libgcc.a(__main.o)          hello.o (__main)
   ./libc.a(exit.o)              crt0.o (_s_exit)
   ./libc.a(strlen.o)            crt0.o (_strlen)
   ./libc.a(_init.o)             crt0.o (_init)
   ./libc.a(atexit.o)            crt0.o (_atexit)
   ./libc.a(loaderstub.o)        crt0.o (_LOADER_NAME)
   ./libc.a(strcpy.o)            crt0.o (_strcpy)
   ./libc.a(path_convert.o)      crt0.o (_path_convert)
   ./libc.a(strrchr.o)           crt0.o (_strrchr)
   ./libc.a(fpinit.obj)          hello.o (_fltused)
   ./libc.a(crt0dat.o)           ./libc.a(_init.o) (_cinit)
   ./libc.a(heapinit.obj)        ./libc.a(_init.o) (_heap_init)
   ./libc.a(malloc.obj)          ./libc.a(atexit.o) (_malloc)
   ./libc.a(strncpy.o)           ./libc.a(path_convert.o) (_strncpy)
   ./libc.a(setlocale.o)         ./libc.a(path_convert.o) (__mb_cur_max)
   ./libc.a(strchr.o)            ./libc.a(path_convert.o) (_strchr)
   ./libc.a(strncmp.o)           ./libc.a(path_convert.o) (_strncmp)
   ./libc.a(strlcpy.o)           ./libc.a(path_convert.o) (_strlcpy)
   ./libc.a(crt0init.obj)        ./libc.a(crt0dat.o) (__xt_z)
   ./libc.a(err.o)               ./libc.a(setlocale.o) (_errx)
   [...]


When linking the same files on interix 3.5 with microsoft's version of 
gnu ld, the link is successful and the generated map begins with:

   $ ld crt0.o hello.o -L. -lgcc -lc -lpsxdll --print-map

   Archive member included because of file (symbol)

   ./libgcc.a(__main.o)          hello.o (__main)
   ./libc.a(exit.o)              crt0.o (_s_exit)
   ./libc.a(strlen.o)            crt0.o (_strlen)
   ./libc.a(_init.o)             crt0.o (_init)
   ./libc.a(atexit.o)            crt0.o (_atexit)
   ./libc.a(loaderstub.o)        crt0.o (_LOADER_NAME)
   ./libc.a(strcpy.o)            crt0.o (_strcpy)
   ./libc.a(path_convert.o)      crt0.o (_path_convert)
   ./libc.a(strrchr.o)           crt0.o (_strrchr)
   ./libc.a(fpinit.obj)          hello.o (_fltused)
   ./libc.a(wk_atexit.o)         ./libgcc.a(__main.o) (atexit)
note this ^^^ line
   ./libc.a(crt0dat.o)           ./libc.a(_init.o) (_cinit)
   ./libc.a(heapinit.obj)        ./libc.a(_init.o) (_heap_init)
   ./libc.a(malloc.obj)          ./libc.a(atexit.o) (_malloc)
   ./libc.a(strncpy.o)           ./libc.a(path_convert.o) (_strncpy)
   ./libc.a(setlocale.o)         ./libc.a(path_convert.o) (__mb_cur_max)
   ./libc.a(strchr.o)            ./libc.a(path_convert.o) (_strchr)
   ./libc.a(strncmp.o)           ./libc.a(path_convert.o) (_strncmp)
   ./libc.a(strlcpy.o)           ./libc.a(path_convert.o) (_strlcpy)
   ./libc.a(crt0init.obj)        ./libc.a(crt0dat.o) (__xt_z)
   [...]


The relevant output from:
   $ nm -p libc.a

   wk_atexit.o:
   000e200c a @comp.id
            U __atexit
            U __atexit
            w _atexit

So the weak symbol _atexit doesn't seem to be handled correctly.

For details how I configured binutils and where to get the files 
mentioned in this mail, see:
http://sourceware.org/bugzilla/show_bug.cgi?id=2729
(The libgcc.a used this time comes from interix.)


Any ideas?


Martin

(please CC me, I'm not on the list!)