Compilation problems

[Marko Kohtala]

Hi all.

Would it be ok to commit some compilation fixes before release?

I tried to cross-compile with mingw and it ran into problems.

The problem is that the the autoconf file configure.ac has these
AC_FUNC_ALLOCA
AC_FUNC_MALLOC
AC_FUNC_MEMCMP
AC_FUNC_REALLOC

but autoconf expects to have replacement functions if it can not find
these to work. In cross compilation it can not test these, so it tries
to use the replacement. Since we do not have the replacement rpl_
functions compilation fails with unresolved symbols at link time.

I've been looking at how to best fix this among these candidates:
- Adding a new lib/libcompat.a
- Adding to libiberty
- Removing the AC_FUNC_ macros from configure.ac
- Using gnulib

Currently I'm leaning towards adding a lib directory where a
libcompat.a is built for these replacement functions. I have some
simple functions already written.

I did not find rpl_malloc and rpl_realloc in libiberty so adding them
there would make it not conform to libiberty in gcc contrary to
request in libiberty/README. Also I feel uncertain about them because
they do not seem to integrate seamlessly with autoconf. memcmp and
alloca included unconditionally header that configure thinks may be
missing.

AC_FUNC_ALLOCA I removed because I did not find alloca() used anywhere.

AC_FUNC_MALLOC should not be removed unless we are sure we do not use
this pattern (from gplink/map.c):
  section_list = malloc(sizeof(gp_section_type *) * state.object->num_sections);
  if (!section_list) {
    fprintf(stderr, "error: out of memory\n");

On some hosts if num_sections is zero, malloc returns NULL and this
will think the allocation failed. (I did not find any place where
something really broke because of this, but I think it better be safe
than sorry.)

gnulib has lots of these replacement functions, but I found they
require adding quite a lot of other supporting stuff like m4 macros,
which seem overkill to me. Besides I'm not familiar enough with them
to know I've used them properly.

Now, if anyone read this far and has some insight to share, I'm interested.

Marko

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Peter Stuge-4]

Marko Kohtala wrote:
> Now, if anyone read this far and has some insight to share, I'm
> interested.

What were you cross-compiling for? Windows has those functions. Maybe
some header file was missing?


//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Marko Kohtala]

On Tue, Mar 10, 2009 at 12:49 PM, Peter Stuge <peter@...> wrote:
> Marko Kohtala wrote:
>> Now, if anyone read this far and has some insight to share, I'm
>> interested.
>
> What were you cross-compiling for? Windows has those functions. Maybe
> some header file was missing?

When cross compiling configure can not execute the test programs
compiled using a cross compiler to verify if malloc(0) returns NULL or
what. So it does the safe thing and replaces calls to malloc with
calls to rpl_malloc and adds the malloc.o to LIBOBJS.

It is wrong to use AC_FUNC_MALLOC in cofigure.ac and not have a
definition for rpl_malloc. See
http://www.gnu.org/software/autoconf/manual/html_node/Particular-Functions.html#index-AC_005fFUNC_005fMALLOC-399

Oh yes, it says AC_FUNC_MEMCMP is "obsolescent". Maybe could just drop that.

Marko

> //Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Marko Kohtala]

I decided to remove the AC_FUNC_ macros.

POSIX malloc(0) may return NULL by definition, and we should write
code so that it works with NULL.

I cleaned up other configure.ac tests also to match what is actually
used by the source. For example many tests used by libiberty.h were
missing.

There are remaining portability problems with hosts that do not have
mempcpy, memset, strchr, strdup, strerror, strrchr, strtol or strtoul.
Could bring those from gcc libiberty, but since no-one cared for them
before, I'll not add them now.

I've committed the changes to svn. I hope they are ok. I ran
testsuites on Linux and cross compiled for i586-mingw32msvc.

Please test if you can.

Marko

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Peter Stuge-4]

Marko Kohtala wrote:
> I've committed the changes to svn. I hope they are ok. I ran
> testsuites on Linux and cross compiled for i586-mingw32msvc.

Awesome! Thanks.


//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...