This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: building newlib for mingw32



Thanks for the help.



The absolute path solved the problem with the incorrect path for the include dirs, if you use /.../newlib-1.11.0/newlib/configure instead of /.../newlib-1.11.0/configure as the README says.


The linking problem still remains, but I'll post that under a different subject.

If anyone cares about the output showing the discrepencies with the README....here's all the details.

--------------------------------------

If you use the top level configure (with absolute or relative paths) as the README says, you get:

bnh-engr at SADIE /e/projects/wincompat-stuff/newlib-1.11.0/i386-mingw
$ /e/projects/wincompat-stuff/newlib-1.11.0/configure --prefix=/e/projects/winc
ompat-stuff/build-newlib
Configuring for a i686-pc-mingw32 host.
Created "Makefile" in /e/projects/wincompat-stuff/newlib-1.11.0/i386-mingw usin
 "mh-frag"


bnh-engr at SADIE /e/projects/wincompat-stuff/newlib-1.11.0/i386-mingw $ make Configuring in etc loading site script /etc/config.site creating cache ../config.cache checking for a BSD compatible install... /bin/install -c updating cache ../config.cache creating ./config.status creating Makefile make[1]: Entering directory `/e/projects/wincompat-stuff/newlib-1.11.0/i386-min w/etc' make[1]: Nothing to be done for `all'.

If you use the configure down inside the newlib directory of newlib-1.11.0, then it goes the the configure of the
whole tree. But, using relative paths, as the README suggests, results in a bad include dir. The include
dir list is okay if you use an absolute path.


By the way, the configure script appears to look for a 'cc' binary to determine if it is a mingw32 environment...mingw32 [ at least
the latest version ] doesn't install a cc.exe, or even a link to gcc.exe. So, it doesn't detect it is a mingw32 environment. If I manually
create a link from cc.exe to gcc.exe, then it does detect the mingw32 environment...I don't know what impact that may have on the
rest of the build.


i.e.:

bnh-engr at SADIE /e/projects/wincompat-stuff/newlib-1.11.0/i386-mingw
$ /e/projects/wincompat-stuff/newlib-1.11.0/newlib/configure --prefix=/e/projec
ts/wincompat-stuff/build-newlib

loading site script /etc/config.site
loading cache ./config.cache
checking for a BSD compatible install... (cached) /bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for Cygwin environment... no
checking for mingw32 environment... no
checking host system type... i686-pc-mingw32
checking target system type... i686-pc-mingw32
checking build system type... i686-pc-mingw32
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... found
checking for gcc... gcc


At 02:02 PM 3/18/2003 -0500, J. Johnston wrote:
I've never tried to build newlib for mingw since, on Windows, newlib is
typically built for cygwin.  However, there seems to at least be a
target for mingw in configure so maybe it's supposed to work.

>We realize we will have to fill in a lot of what windows doesn't natively
>provide [ i.e. system calls ] but we were hoping to use newlib to
>accomplish some of what we couldn't accomplish easily with liberty & mingw.


Filling in a lot of what windows doesn't natively do is actually what cygwin
does.

We can't use Cygwin due to licensing restrictions.


>Problem 1: configure. I've followed the README, but the configure script in
>the top level build directory does not recurse.
> And, if I use ../../newlib/configure, then the include path
> is wrong, and the .c's can't find libc/include.


Sorry, but you're not providing many details.  As a wild guess, perhaps
you shouldn't be using relative paths to configure but should be
building in a completely separate build directory.  That's how I typically
build newlib for cygwin.

I'm following the README in the newlib distribution verbatim.

Brian, try using an absolute path to newlib's configure. If you still have the same problems, then please post your configuration line and what errors you are seeing on the make.

If you could also post an example of what errors you are seeing in
mallocr.o, it would make it easier to assist you.

Otherwise, please provide your directory layout, the commands you're using
to configure and make newlib, an example gcc command line, and exact error
message output.

>Problem 2: I worked around problem 1 manually. I then created stubs for all
>the system calls that newlib makes [ and it makes a few ], I will fill them
>out later.
> But, I get linker errors complaining that gcleanup and wsbrk
> are multiply defined...i.e. in freer.o and mallocr.o.


Sorry.  Can't help there.  Again, details would help, like the actual gcc
command line you're using.
\


+==========================================================+ Brian N. Hawley bhawley at luminex dot com Luminex Software, Inc. http://www.luminex.com PO Box 5908 voice: 909-781-4100 x112 Riverside, CA 92517 fax: 909-781-4105 +==========================================================+



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]