This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: Make collect2 be buildable when host=i386-mingw,target=something else


DJ Delorie <dj@redhat.com> writes:

>> collect2 wants to do different things: either create a pipe between
>> child and parent, or redirect child's stdout to a temporary file.
>
> I wonder why they didn't just use popen() or system() for those.

They don't take argument vectors, and you have to deal with quoting
and shell syntax.

>> Since DJGPP does not have concurrent processes to worry about, you
>> could use a temporary file, just as command.com does when "|" appears
>> on a command line.
>
> Right, but I meant creating an API based on the fundamental concepts
> of pipes existing seems wrong to me - it means we've got the wrong
> abstraction.

I'm open to suggestions, but really, DJGPP is the aberration here;
every other supported system has pipes, so why not fake them on DJGPP
so the application doesn't have to care?

>> I don't see why this patch should be blocked on a global cleanup
>> operation which is totally orthogonal to its own aims.
>
> In general, I don't like taking things out of libiberty's API space.
> So if there's going to be a change that causes part of the API to go
> away, waiting a bit until the change happens means one less API to
> expose to the public and then take away.

... except that the cleanup *is not going to happen* until after I get
collect2 working on windows, or anyway it ain't going to be me doing
it.

zw


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