[haiku-development] Re: building under Cygwin (windows)

  • From: "Urias McCullough" <umccullough@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 2 Jun 2007 14:46:14 -0700

On 5/30/07, Stefano Ceccherini <stefano.ceccherini@xxxxxxxxx> wrote:
2007/5/30, Oliver Tappe <zooey@xxxxxxxxxxxxxxx>:
Hi Oliver,
thank you for your reply.

> It seems that cygwin's linker does not allow multiple instances of the same
> symbol, probably due to existing binary format rules on Windows.
>
> Could you please try to invoke the linker command manually and add '-z 
muldefs'
> to it? I am not even sure the cygwin linker supports that option, but if it
> does work this way, it could be possible to add this option to the build of
> host-tools on the cygwin platform...

It doesn't support -z muldefs, but it supports
--allow-multiple-definition. I added it, and the previous error
doesn't show up anymore, but still it doesn't link (see other
message).

I was searching around for information on cygwin's linker issues - and
ran across something in the ncurses configure script - it considers
cygwin's linker to be "BROKEN_LINKER=1" - and there's a configure
option to allow it:

   --enable-broken_linker
        A few platforms have what we consider a broken linker:  it cannot link
        objects from an archive solely by referring to data objects in those
        files, but requires a function reference.  This configure option
        changes several data references to functions to work around this
        problem.

        NOTE:  With ncurses 5.1, this may not be necessary, since we are
        told that some linkers interpret uninitialized global data as a
        different type of reference which behaves as described above.  We have
        explicitly initialized all of the global data to work around the
        problem.

I'm wondering if that's part of the issue here?

There's an example in the ncurses include/tic.h:

struct tinfo_fkeys {
        unsigned offset;
        chtype code;
        };

#ifdef  BROKEN_LINKER

#define _nc_tinfo_fkeys _nc_tinfo_fkeysf()
extern struct tinfo_fkeys *_nc_tinfo_fkeysf(void);

#else

extern struct tinfo_fkeys _nc_tinfo_fkeys[];

#endif

Anyhow, that's all I can find.  I tried executing the ld command
directly without using cc and it spits out no visible errors (appears
to succeed) but neglects to create the target file anyway.

- Urias

Other related posts: