need_the_occasional_chunk_of_libio=yes
Benjamin Kosnik
bkoz@redhat.com
Tue Oct 24 15:54:00 GMT 2000
> What's happening is that iofwide.c (an XTRA file) contains wide-char
> functions that are referenced when WSRCS are built, causing a linker
> failure. My patch duplicates iofwide.c in both lists, but when both
> groups are active the duplication doesn't get flattened early enough,
> leading to duplicate symbols in the linker on other systems.
Hmm. Yes, non-duplicated would be cleaner.
> I'm wanting to make the acinclude.m4 enable_libio logic a bit smarter.
logic is pretty a pretty generous way to describe it at the moment.
> But I need a little explanation. Right now it's
>
> if <libio.h> exists
> if glibc 2.2 is satisfactory
> need_libio = no
> need_xtra_libio = no
> need_wlibio = no
> else
> need_libio = yes
> need_xtra_libio = yes
> need_wlibio = maybe
> else
> need_libio = yes
> need_xtra_libio = no ??
> need_wlibio = maybe
ok. Here's the thought:
1) eventually, when libstdc++/glibc have a merged libio, libstdc++ won't
have to build libio. Thus, the checks for glibc
AT the moment, it's not merged exactly so all platforms build libio
HOwever, the machinery to select this should be preserved.
> where "maybe" == "conditional on the user's configure flags" and defaults
> to yes. Also note that right now we force the satisfactory test to false.
>
> I'm usually in that last branch, where glibc/libio isn't installed at all, so
> we need to build most of it. Shouldn't need_xtra_libio be yes in that case?
yes
> For that matter, what's the distinction between the files in 'libio' and
> the ones in 'xtra_libio'? I'd be glad to rework it to bring it closer
> to reality.
right. I guess the logic should be:
1) if you have all of libio already, disable
2) if you don't have libio
a) if you need wide stuff, enable all
b) if you need just narrow stuff, enable only narrow
hope this helps.
benjamin
More information about the Libstdc++
mailing list