Menu
▾
▴
#154 Building coreutils from source package fails
coreutils-5.97:
configure: error: could not determine how to read list of mounted file systems
- after manually removing the respective section in the configure script:
make: *** No rule to make target `../m4/extensions.m4', needed by `Makefile.in'. Stop.
Not a MinGW bug.
Although your problem may be interesting and causing you problems you wish answers to, it is not a problem with the MinGW runtime,
w32api, GCC, binutils or msys. Your BUG report has therefore been deleted. If you feel that this needs further discussion then
please post to mingw-users@lists.sourceforge.net.
Thanks for your interest in the MinGW Project,
MinGW Project Administrators
I'm tentatively flagging this as invalid; it isn't a MinGW bug, when you can't build a package after you've manually ripped out part of its build system.
It is not at all clear what you are trying to accomplish. If you are trying to build a native MinGW coreutils, then that will likely require significant porting effort. Again, it isn't a MinGW bug that you need to do this. If you want help with such a venture, then this isn't the place to seek it; use the mailing list.
If you really want to convince me that this is a MinGW bug, then you need to provide much more detail of what you are trying to accomplish, how you have set about it, and why you conclude that it is a MinGW bug.
What is your environment when doing this?
Use ``uname -a'' to tell us.
@comment 1:
From uname: it's 1.0.17(0.48/3/2) 2011-04-24
@comment 2:
I didn't "rip out" a part - I carefully disabled the part that had caused the first failure in its *original* form (just to find there are further failures which I also reported - no reason to reject the bug on this part).
I'm not trying to port anything new. I'm just trying to compile a MinGW source package which I downloaded with mingw-get source ... - from which I should assume the current distribution has been built. If that doesn't work, something is broken within the MinGW system.
Purpose: Analyze the way a MinGW program is linked to check what may be missing in my own project.
@comment 3:
After you requested further information from me I would expect and appreciate if you await my reponse before you speak about closing or even deleting a bug.
You are confusing two simultaneous responses, from two different project administrators; Earnie asked you to provide the output from "uname -a", (which you have not done; you've omitted the most important piece of the information that would have given us -- the system name).
It was I who said that I don't believe this to be a valid MinGW bug report, for the following reasons:--
* You said you had modified the configure script: ergo it is no longer a standard MinGW or MSYS package; you broke it, so you get to keep all the pieces.
* You didn't even say you were trying to build from a MinGW source package, and indeed, there is no MinGW package for coreutils.
* In the absence of the above information, I assumed that you are trying to build either from upstream coreutils source, or from our *MSYS* package, and you are (inappropriately) using MinGW development tools.
Notwithstanding these assumptions, I did *NOT* close the ticket without giving you an opportunity to respond -- I marked it as "pending/invalid", giving you 30 days to respond, and to clarify my assumptions, before the bug tracking system would automatically close the ticket.
I see nothing in your responses, to date, to cause me to modify my assumptions, (beyond that I now know it is the *MSYS* source package you are using [*]). I am still left to assume that you are trying to build this with MinGW development tools, where you should be using the MSYS specific tools; if this assumption is correct, then I stand by original assessment that this is not a MinGW bug.
[*] Again, you didn't explicitly tell me this, but I deduce it, since:--
mingw-get source coreutils
delivers nothing at all, (fails silently, which is another bug, for another ticket). To get coreutils source, via mingw-get, you must:
mingw-get source msys-coreutils
The clue is in the "msys-" prefix; this is an *MSYS* package, and there will be instructions within the source package itself, explaining how to build it as such. If the documented build method doesn't work, then you may have a valid case for submitting a bug report; OTOH, if you just need clarification of, or help with following that method, then you will not get it here; use the MinGW-Users mailing list.
Well, you had also asked me for information (about what I was trying to accomplish and why it should be a bug...); also, as I said, I did not modify the package before the first failure occurred.
Anyway -
Thanks for pointing out (also in that other bug) the strict distinction between MinGW and MSYS. Actually this comes somehow as a surprise considering the strong intertwining of their web distribution and installation - maybe some clearer introduction somewhere could be helpful to others; I had indeed not been aware that there is a separate MSYS development toolkit.
[Meta comment]
Lowering priority, after clarification, just to check whether there is a "red warning" as you claimed in the other bug. There is none before clicking "Update" at least.
(And if you don't like users to suggest priorities, it should not be possible in the first place.)
The reason I asked for uname -a output was to determine the build environment. I indeed thought as Keith did but didn't want to make the assumption by default. We warn that the user shouldn't set the priority or make an assignment on the initial screen, that is all we can do.
Given that you were not in the correct environment I'm modifying this to a support request.