victory! I have a working crosscompiler!

victory! I have a working crosscompiler!

[Adam Megacz]

And it even says "hello world"! =)

Thanks for all your help, people.

I'll be submitting some patches as soon as I figure out what to do
about libc and libstdc++ (I know that libc is "a UNIX thing" -- is
libstdc++ also "a UNIX thing"?)...

  - a

Re: victory! I have a working crosscompiler!

[Bo Thorsen]

On Sunday 09 December 2001 03:57, Adam Megacz wrote:
> And it even says "hello world"! =)
>
> Thanks for all your help, people.
>
> I'll be submitting some patches as soon as I figure out what to do
> about libc and libstdc++ (I know that libc is "a UNIX thing" -- is
> libstdc++ also "a UNIX thing"?)...

Not true. If you have a C compiler, you have a C library. If you have a C++ 
compiler, you have a standard C++ library. If one of these is not true, what 
you have is not a valid compiler.

This has nothing to do with operating systems.

Bo.

-- 

     Bo Thorsen                 |   Praestevejen 4
     Free software developer    |   5290 Marslev
     SuSE Labs                  |   Denmark

Re: victory! I have a working crosscompiler!

[Adam Megacz]

Bo Thorsen <bo@sonofthor.dk> writes:
> Not true. If you have a C compiler, you have a C library.

But I've never seen a file called "libc.so" on a windows machine.

And (for example), getpwent() is part of libc, yet (AFAIK) is pretty
much meaningless on a Win32 system.

This is why I'm so confused...

Argh, I should just stick to UNIX =)

  - a

Re: victory! I have a working crosscompiler!

[Zack Weinberg]

On Mon, Dec 10, 2001 at 02:11:47PM -0500, Adam Megacz wrote:
> 
> Bo Thorsen <bo@sonofthor.dk> writes:
> > Not true. If you have a C compiler, you have a C library.
> 
> But I've never seen a file called "libc.so" on a windows machine.
> 
> And (for example), getpwent() is part of libc, yet (AFAIK) is pretty
> much meaningless on a Win32 system.

As I understand it, libc.so is roughly analogous to the core DLLs:
kernel32, etc.  Look in gcc/config/i386/mingw32.h and cygwin.h for
some lists.

The interfaces defined by the C standard will be provided by some
library - that's what Bo means.  Some of the interfaces defined by
POSIX are present too, more with cygwin.  Very unix-specific routines
like getpwent naturally won't show up.

It's a historical accident that libc.so contains all the stuff it
does.  In fact, you can make a good design case for splitting it up by
standard and interface level.  (Some systems have a libsys.a that
contains nothing but the primitive system calls, for use by programs
that don't want the C runtime.  Unfortunately it doesn't work with
dynamic linking.)

zw

Re: victory! I have a working crosscompiler!

[Craig Rodrigues]

On Mon, Dec 10, 2001 at 02:11:47PM -0500, Adam Megacz wrote:
> 
> Bo Thorsen <bo@sonofthor.dk> writes:
> > Not true. If you have a C compiler, you have a C library.
> 
> But I've never seen a file called "libc.so" on a windows machine.

But you've seen MSVCRT.DLL haven't you?

If you have the dumpbin.exe program that comes with Visual C++, you
can do:
dumpbin /exports MSVCRT.DLL

If you use Cygwin, that includes its own C library.
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

Re: victory! I have a working crosscompiler!

[Andreas Schwab]

Adam Megacz <gcc@lists.megacz.com> writes:

|> Bo Thorsen <bo@sonofthor.dk> writes:
|> > Not true. If you have a C compiler, you have a C library.
|> 
|> But I've never seen a file called "libc.so" on a windows machine.
|> 
|> And (for example), getpwent() is part of libc, yet (AFAIK) is pretty
|> much meaningless on a Win32 system.

getpwent is POSIX, and if you have a POSIX system, you have getpwent.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: victory! I have a working crosscompiler!

[Christopher Faylor]

On Mon, Dec 10, 2001 at 11:31:06AM -0800, Zack Weinberg wrote:
>On Mon, Dec 10, 2001 at 02:11:47PM -0500, Adam Megacz wrote:
>>Bo Thorsen <bo@sonofthor.dk> writes:
>>>Not true.  If you have a C compiler, you have a C library.
>>
>>But I've never seen a file called "libc.so" on a windows machine.
>>
>>And (for example), getpwent() is part of libc, yet (AFAIK) is pretty
>>much meaningless on a Win32 system.
>
>As I understand it, libc.so is roughly analogous to the core DLLs:
>kernel32, etc.  Look in gcc/config/i386/mingw32.h and cygwin.h for some
>lists.
>
>The interfaces defined by the C standard will be provided by some
>library - that's what Bo means.  Some of the interfaces defined by
>POSIX are present too, more with cygwin.  Very unix-specific routines
>like getpwent naturally won't show up.

getpwent does show up with cygwin.  Cygwin implements a substantial
number of "UNIX" functions.

In the cygwin case, there is a libc.a but it is linked to libcygwin.a.
On starrtup, a program automatically loads cygwin1.dll in an analogous
way to libc.so.  cygwin1.dll contains most of the functions found in a
normal libc.so.  cygwin1.dll makes calls to other system DLLs.

The equivalent for mingw is something like libmsvcrt40.a/msvcrt40.dll
(and libmingwm10/mingwm10.dll).  msvcrt40.dll is a Microsoft provided
DLL.  There are many fewer 'UNIX' like functions available under mingw,
for obvious reasons.

I've lost the thread of the reason for the original query but I can't
think of a good reason why you need to know precisely what your C
library is called.  The library gets linked in automatically just like
it does on any UNIX system.  You shouldn't have to figure out precisely
what it's called.  Just use it.

If you want to know if a particular function is available under a
particular Windows UNIX-emulation the best way is to just try to link
it and note any errors.

cgf

Re: victory! I have a working crosscompiler!

[DJ Delorie]

> But I've never seen a file called "libc.so" on a windows machine.

It's crtdll.dll for mingw, and cygwin1.dll for cygwin.  For DJGPP it's
libc.a (no shared libs).

Re: victory! I have a working crosscompiler!

[Adam Megacz]

Christopher Faylor <cgf@redhat.com> writes:
> On Mon, Dec 10, 2001 at 11:31:06AM -0800, Zack Weinberg wrote:
> >On Mon, Dec 10, 2001 at 02:11:47PM -0500, Adam Megacz wrote:
> >>Bo Thorsen <bo@sonofthor.dk> writes:
> >>And (for example), getpwent() is part of libc, yet (AFAIK) is pretty
> >>much meaningless on a Win32 system.

> getpwent does show up with cygwin.  Cygwin implements a substantial
> number of "UNIX" functions.

I was referring to Win32 (ie MinGW), not Cygwin.

I guess I'd summarize my question (and the answer supplied) as "yes,
some sort of C library will accompany every compiler, but on many
platforms it will not be glibc, nor will it look even vaguely like
glibc".

So, popping back up one level to my original question, we can assume
that every platform will have some sort of c++ library. However, will
libstdc++-v3 always be able to fill this role (unlike glibc), or is
libstdc++-v3 only suitable for POSIX systems (as is glibc)?

Again, when I say windows, win32, or "non-POSIX platforms", I don't
mean cygwin.


> I can't think of a good reason why you need to know precisely what
> your C library is called.  The library gets linked in automatically
> just like it does on any UNIX system.  You shouldn't have to figure
> out precisely what it's called.  Just use it.

There are lines in gcc's Makefiles that include the switch "-lc"
(implying the filename "libc.so").

Specifically, this happens when cross-compiling libstdc++-v3 from
linux to mingw32, without --disable-shared.


  - a

Re: victory! I have a working crosscompiler!

[Adam Megacz]

Craig Rodrigues <rodrigc@mediaone.net> writes:
> > But I've never seen a file called "libc.so" on a windows machine.

> But you've seen MSVCRT.DLL haven't you?

Sure, but "ld -lc" isn't going to be able to find that.

  - a

Re: victory! I have a working crosscompiler!

[Phil Edwards]

On Mon, Dec 10, 2001 at 03:48:55PM -0500, Adam Megacz wrote:
> So, popping back up one level to my original question, we can assume
> that every platform will have some sort of c++ library. However, will
> libstdc++-v3 always be able to fill this role (unlike glibc), or is
> libstdc++-v3 only suitable for POSIX systems (as is glibc)?

Right now libstdc++-v3 assumes a lot of POSIX semantics, because nobody has
contributed code to allow it to do otherwise.  In the major cases (e.g.,
underlying I/O library), hooks and wrappers are in place to support something
completely non-POSIX, but nobody has yet taken advantage of them[*].

[*]  And told us about it.[**]
[**] "And lived to tell about it" might be more appropriate.  :-)


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: victory! I have a working crosscompiler!

[Adam Megacz]

Phil Edwards <pedwards@disaster.jaj.com> writes:
> Right now libstdc++-v3 assumes a lot of POSIX semantics, because nobody has
> contributed code to allow it to do otherwise.  In the major cases (e.g.,
> underlying I/O library), hooks and wrappers are in place to support something
> completely non-POSIX, but nobody has yet taken advantage of them[*].

Thanks, Phil!

So I guess the final answer is that I shouldn't worry if libstdc++-v3
doesn't build properly when creating a linux-to-mingw crosscompiler,
since mingw doesn't support the POSIX API.

Thanks again.

  - a

Re: victory! I have a working crosscompiler!

[Danny Smith]

 
Adam Megacz <gcc at lists dot megacz dot com> wrote
>>Phil Edwards <pedwards@disaster.jaj.com> writes:
>> Right now libstdcv3 assumes a lot of POSIX semantics, because nobody has
>> contributed code to allow it to do otherwise.  In the major cases (e.g.,
>> underlying I/O library), hooks and wrappers are in place to support
something
>>completely non-POSIX, but nobody has yet taken advantage of them[*].

> Thanks, Phil!

> So I guess the final answer is that I shouldn't worry if libstdcv3
> doesn't build properly when creating a linux-to-mingw crosscompiler,
> since mingw doesn't support the POSIX API.

No, that is not final answer. It does support the stdio_file_model, and
libstdc++v3 does build natively on mingw with that model (selected by
configure).  There are missing bits in locale functionality (needs hooks
into native w32api, which is a wip) and there are missing wchar bits (due
to missing support in the C runtime) and others, but all told I was very
pleasantly surpised at how easily it did build natively on mingw32.

Danny
Danny


http://shopping.yahoo.com.au - Yahoo! Shopping
- Free CDs for thousands of Priority Shoppers!