Re: [Elftoolchain-developers] windows porting...

[Gorton, R. <Ric...@am...>]

I'm doing a native port to visual studio; we've got a build environment which uses a tool called bjam to do the compilations.  As for the existing makefiles, I'll observe that gnu make (under ubuntu/64-bit) objects to ".include <bsd.subdir.mk>" in the top level makefile.  I haven't looked at the tests at all.

Rick

-----Original Message-----
From: ko...@un... [mailto:ko...@un...] On Behalf Of Joseph Koshy
Sent: Saturday, October 09, 2010 1:35 AM
To: Gorton, Richard
Cc: elf...@li...
Subject: Re: [Elftoolchain-developers] windows porting...

> I've got a need to port elftoolchain to Windows, and am in the
  process of doing so.

Best of luck!  Our current porting targets are open-source POSIX
systems. To the best of our knowledge, you would be the first person
attempting a Windows(R) port.

Changes that improve our code's portability would be welcome.

Its also fair to point out upfront that we don't currently have a way
to develop for the Windows(R) platform, so ongoing maintenance may be
an issue unless someone with Windows expertise steps up to
periodically build the code and keep it "live".

> Are there any particular process requirements in terms of feeding
  back the changes to get them integrated?

Just file a Trac ticket with your patch and we'll take it forward from
there.

>  A preferred diff command?

Any readable format will do, e.g., `diff -u`.

> My motivation here is to get a completely clean compile with no warnings.

Cool.

Some questions:

1) What build environment are you using?  Is it open-source?

2) How are you handling make rules---our makefiles are dependent on
   <sys.mk> doing the right thing.

3) libelf uses mmap() internally; how much of a portability hurdle is
   this?

4) Finally, are you attempting to port the test suites too?  If so,
   any issues there?


[...snip...]

> Another choice is to explicitly cast size --> size_t knowing that
  the realloc() is always going to be < 32bits in size.

In this case a (size_t) cast should be good enough---it would be a
no-op on 64 bit systems, and 32 bit POSIX-like systems aren't going to
be able to deal with memory arenas larger than process address space
anyway.

-- Koshy