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

See the CrossGCC FAQ for lots more information.


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

Cygwin && glibc build notes


Folks,

  I thought some of you building Cygwin-hosted cross compilers might be
interested in a couple of things that I've managed to ferret out over the
past couple of weeks.

  The builds I'm working on go something like this:

  - build binutils for target
  - build gcc for target using newlib
  - build glibc for target using gcc-newlib for target
  - build gcc for target using glibc

  The first problem was getting glibc to build properly with
--enable-shared.  Since NTFS is a case-insensitive filesystem, it's
unable to tell the difference between the results of building a file
for inclusion in a shared object (.os) or a static library (.oS).
This means that specifying --enable-shared results in non-shared code
ending up in shared libraries, and vice versa... if libc_nonshared.a
is over a few K in size, then you've probably run into this problem.

  AFAICT, this naming convention has been a part of glibc since
--enable-shared was introduced.  The fix is fairly simple: modify the
glibc Makeconfig and Makerules to use an object extension other than
.oS for object files that are to be included in libc_nonshared.a.

  The second problem is related to the second stage build of gcc using
glibc.  I posted a message about this a while back:

  http://sources.redhat.com/ml/crossgcc/2001-09/msg00027.html

  Symptoms are that the gcc/libiberty configure script tries to execute
cross-compiled binaries as part of the configure process, causing Windows
to pop up a dialog box complaining of an illegal instruction.

  I managed to stumble across this link which describes the problem:

  http://www.oarcorp.com/rtems/maillistArchives/rtems-users/2001/march/msg00178.html

  Configure builds and tries to execute a binary in order to see if the
version of gcc it's using is a cross-compiler.  If execution fails, then
it assumes that the version of gcc being used is a cross-compiler.

  Under Windows, if an executable is not in PE format, the OS assumes
that it's a 16-bit COM image, and tries to execute it as such.  This
is pretty much guaranteed to result in an illegal instruction exception.
The simplest way to avoid this is to disable the Windows 16-bit subsystem:

1) Fire up the registry editor.
2) Find the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW
3) Change the value of 'cmdline' from '%SystemRoot%\system32' to
   '_%SystemRoot%\system32' (note the leading underscore.)

  This disables the OS's ability to run non-GUI 16-bit executables.
Note that there is another value (wowcmdline) that is used to run 16-bit
GUI executables.  You do not need to disable this in order to get the
second pass of GCC to build properly.

  Hope this all helps someone somewhere sometime,

-Samrobb



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


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