The situation with chown and dirname

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

The situation with chown and dirname

krzysztof.zelechowski
The chown API is available in MSYS but not in MinGW.
The chown tool is supported, although does not use the implementation from
MSYS, it uses its own one.  This implementation sets errno=EPERM; the
correct value would be ENOSYS (or whatever happens in Unix when you chmod on
a FAT volume).
The dirname API is available in MinGW but not in MSYS.
Additionally, MSYS supports realpath and mkstemp but MinGW does not.
The object files from MinGW do not work in MSYS and probably vice versa.
The implementation of dirname in MinGW has an unnecessary dependency on a
header file that makes it break in MSYS.  This is easy to fix by removing
the inclusion.
Could you please bring this mess in order?  Like, make everything work
everywhere?
Best regards,
Chris



------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

Eli Zaretskii
> From: <[hidden email]>
> Date: Mon, 4 Aug 2014 21:35:22 +0200
>
> The chown API is available in MSYS but not in MinGW.
> The chown tool is supported, although does not use the implementation from
> MSYS, it uses its own one.  This implementation sets errno=EPERM; the
> correct value would be ENOSYS (or whatever happens in Unix when you chmod on
> a FAT volume).
> The dirname API is available in MinGW but not in MSYS.
> Additionally, MSYS supports realpath and mkstemp but MinGW does not.
> The object files from MinGW do not work in MSYS and probably vice versa.
> The implementation of dirname in MinGW has an unnecessary dependency on a
> header file that makes it break in MSYS.  This is easy to fix by removing
> the inclusion.
> Could you please bring this mess in order?  Like, make everything work
> everywhere?

It's not a mess: MinGW and MSYS are two subtly incompatible
environments.  They use 2 different standard C libraries and 2
different runtime environments.  MSYS was tamed enough to be able to
invoke MinGW programs, but that's where the compatibility ends.

That said, I'm sure patches to make "everything work everywhere" will
be gladly accepted.

Failing that, perhaps you would care to explain where and how does
this get in your way, and if you have practical problems, chances are
someone here will be able to help you solve them.

------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

krzysztof.zelechowski
MSYS has a tool named chown and an implemented API named chown.  Normally
the tool would call the API, but it has a separate implementation in
coreutils.  This is what I may safely call "mess", MinGW has nothing to do
with this particular case, or with the error value returned (which is
wrong).
The implementation of dirname in MinGW has an unnecessary dependency on a
header file.  This is easy to fix by removing  the inclusion.  This is what
I may safely call "mess", MSYS has nothing to do with this.
So stop covering yourself with the "incompatible by design" fig leaf and
face the reality.

My problem is that I need the API provided by MSYS and a selection of the
API added in libmingwex.  I have not  yet decided whether the program should
be a MSYS tool or not; however, it seems it will feel better living in the
MSYS world.  I am worried, however, that the file sniffer compiled (from
source) as an MSYS tool is broken and cannot read anything; I suppose the
reason is that MSYS has a different concept of regular expressions than
libmagic.  (The tool does not suffer any breakage when compiled under MinGW
+ libgnurx, or whatever it is called.)  Maybe I should compile libgnurx for
MSYS and the problem will go away.  Maybe I could compile the relevant
fragment of libmingwex to provide dirname.  But I must say this crime scene
that you have left disappoints me a lot.

Maybe I could submit patches if you say that could in principle be
acceptable.  But I am afraid I need to understand this broken-by-design
concept of yours first.  The situation on Windows is easier in that you do
not need any patches to build things; you just go and edit the source files,
which is what I do without any shame, remorse or respect to your authority.

Best regards,
Chris.

Użytkownik "Eli Zaretskii"  napisał w wiadomości grup
dyskusyjnych:[hidden email]...

> From: <[hidden email]>
> Date: Mon, 4 Aug 2014 21:35:22 +0200
>
> The chown API is available in MSYS but not in MinGW.
> The chown tool is supported, although does not use the implementation from
> MSYS, it uses its own one.  This implementation sets errno=EPERM; the
> correct value would be ENOSYS (or whatever happens in Unix when you chmod
> on
> a FAT volume).
> The dirname API is available in MinGW but not in MSYS.
> Additionally, MSYS supports realpath and mkstemp but MinGW does not.
> The object files from MinGW do not work in MSYS and probably vice versa.
> The implementation of dirname in MinGW has an unnecessary dependency on a
> header file that makes it break in MSYS.  This is easy to fix by removing
> the inclusion.
> Could you please bring this mess in order?  Like, make everything work
> everywhere?

It's not a mess: MinGW and MSYS are two subtly incompatible
environments.  They use 2 different standard C libraries and 2
different runtime environments.  MSYS was tamed enough to be able to
invoke MinGW programs, but that's where the compatibility ends.

That said, I'm sure patches to make "everything work everywhere" will
be gladly accepted.

Failing that, perhaps you would care to explain where and how does
this get in your way, and if you have practical problems, chances are
someone here will be able to help you solve them.

------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette
may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also:
mailto:[hidden email]?subject=unsubscribe



------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

Eli Zaretskii
> From: <[hidden email]>
> Date: Thu, 7 Aug 2014 01:33:44 +0200
>
> MSYS has a tool named chown and an implemented API named chown.  Normally
> the tool would call the API, but it has a separate implementation in
> coreutils.  This is what I may safely call "mess", MinGW has nothing to do
> with this particular case, or with the error value returned (which is
> wrong).

Assuming you are right (I didn't check), there's no mess here.  It is
entirely legitimate for a program to bypass APIs, especially since
chown in its Posix sense makes very little sense on Windows.

> The implementation of dirname in MinGW has an unnecessary dependency on a
> header file.  This is easy to fix by removing  the inclusion.  This is what
> I may safely call "mess"

No, that is at best a minor bug.

> So stop covering yourself with the "incompatible by design" fig leaf and
> face the reality.

I'm not covering anything, just trying to help you overcome the
terrible confusion you are evidently in.

> My problem is that I need the API provided by MSYS and a selection of the
> API added in libmingwex.  I have not  yet decided whether the program should
> be a MSYS tool or not; however, it seems it will feel better living in the
> MSYS world.  I am worried, however, that the file sniffer compiled (from
> source) as an MSYS tool is broken and cannot read anything; I suppose the
> reason is that MSYS has a different concept of regular expressions than
> libmagic.  (The tool does not suffer any breakage when compiled under MinGW
> + libgnurx, or whatever it is called.)  Maybe I should compile libgnurx for
> MSYS and the problem will go away.  Maybe I could compile the relevant
> fragment of libmingwex to provide dirname.  But I must say this crime scene
> that you have left disappoints me a lot.

You are mixing MSYS and MinGW sources and libraries.  This will never
work.  In particular, MinGW libraries will never work with MSYS
executables and vice versa.  Pick up one (I suggest MinGW), and stick
with it.

------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

Keith Marshall
On 07/08/14 16:49, Eli Zaretskii wrote:

>> From: <[hidden email]>
>> Date: Thu, 7 Aug 2014 01:33:44 +0200
>>
>> MSYS has a tool named chown and an implemented API named chown.  Normally
>> the tool would call the API, but it has a separate implementation in
>> coreutils.  This is what I may safely call "mess", MinGW has nothing to do
>> with this particular case, or with the error value returned (which is
>> wrong).
>
> Assuming you are right (I didn't check), there's no mess here.  It is
> entirely legitimate for a program to bypass APIs, especially since
> chown in its Posix sense makes very little sense on Windows.

This is true.  The chown API will have been inherited from the original
cygwin implementation, of which MSYS is a fork; it is known to be not
well supported in its MSYS incarnation, and the MSYS objectives do not
require it, so don't expect the MSYS maintainers to attach any urgency
to a follow-up.  Furthermore, the chown tool in MSYS coreutils has been
sequestered into the auxiliary package, provided only because they are
components of upstream coreutils, *documented* as not required to meet
MSYS objectives, not well tested, and probably unlikely to work.

>> The implementation of dirname in MinGW has an unnecessary dependency on a
>> header file.  This is easy to fix by removing  the inclusion.  This is what
>> I may safely call "mess"
>
> No, that is at best a minor bug.

And, since he has declined to specify what he means by an "unnecessary
header file dependency", it may not even be that; I'm certainly not
going to engage in blind speculation, on the basis of vague innuendo.

>> So stop covering yourself with the "incompatible by design" fig leaf and
>> face the reality.
>
> I'm not covering anything, just trying to help you overcome the
> terrible confusion you are evidently in.

Evidently.

>> My problem is that I need the API provided by MSYS and a selection of the
>> API added in libmingwex.  I have not  yet decided whether the program should
>> be a MSYS tool or not; however, it seems it will feel better living in the
>> MSYS world.  I am worried, however, that the file sniffer compiled (from
>> source) as an MSYS tool is broken and cannot read anything; I suppose the
>> reason is that MSYS has a different concept of regular expressions than
>> libmagic.  (The tool does not suffer any breakage when compiled under MinGW
>> + libgnurx, or whatever it is called.)  Maybe I should compile libgnurx for
>> MSYS and the problem will go away.  Maybe I could compile the relevant
>> fragment of libmingwex to provide dirname.  But I must say this crime scene
>> that you have left disappoints me a lot.
>
> You are mixing MSYS and MinGW sources and libraries.  This will never
> work.  In particular, MinGW libraries will never work with MSYS
> executables and vice versa.

<Sigh> How many times must we repeat this?  Like Eli says, you simply
must *never* try to mix MSYS and MinGW libraries, or their associated
headers, into the build of any single executable.

> Pick up one (I suggest MinGW), and stick with it.

Sound advice.  Heed it.

--
Regards,
Keith.

------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

krzysztof.zelechowski
In reply to this post by Eli Zaretskii
MSYS API is missing only basename and dirname while MinGW is missing lots of
things: chown, mkstemp, realpath.  Basename and dirname from libmingwex are
easily portable to MSYS; all you have to do is to remove the unnecessary
inclusion.  So I suppose I shall get better results with the direction MinGW
to MSYS than the other way round.

I do not expect chown do do anything in particular, except that I consider
ENOSYS to be a better diagnostic than EPERM.

Thanks,
Chris



------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

Eli Zaretskii
> From: <[hidden email]>
> Date: Sat, 9 Aug 2014 00:14:56 +0200
>
> MSYS API is missing only basename and dirname while MinGW is missing lots of
> things: chown, mkstemp, realpath.  Basename and dirname from libmingwex are
> easily portable to MSYS; all you have to do is to remove the unnecessary
> inclusion.  So I suppose I shall get better results with the direction MinGW
> to MSYS than the other way round.

What are you trying to accomplish?  Which program or package are you
trying to compile that need these functions?

There are replacements available out there for mkstemp and realpath,
but the question is: do you really need them, and why?

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

krzysztof.zelechowski
I do not know why the program I am trying to build needs mkstemp and
realpath, it checks for these in configure.  I have not passed through
configure yet, so I cannot tell what they are really used for.
However, let me say that mkstemp is indispensable in most programs—and
Microsoft Windows is notorious for its poor support for temporary files.
Even MS–DOS had better support in that regard.
Thanks,
Chris

Użytkownik "Eli Zaretskii"  napisał w wiadomości grup
dyskusyjnych:[hidden email]...

> From: <[hidden email]>
> Date: Sat, 9 Aug 2014 00:14:56 +0200
>
> MSYS API is missing only basename and dirname while MinGW is missing lots
> of
> things: chown, mkstemp, realpath.  Basename and dirname from libmingwex
> are
> easily portable to MSYS; all you have to do is to remove the unnecessary
> inclusion.  So I suppose I shall get better results with the direction
> MinGW
> to MSYS than the other way round.

What are you trying to accomplish?  Which program or package are you
trying to compile that need these functions?

There are replacements available out there for mkstemp and realpath,
but the question is: do you really need them, and why?



------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

Eli Zaretskii
> From: <[hidden email]>
> Date: Sat, 9 Aug 2014 13:31:13 +0200
>
> I do not know why the program I am trying to build needs mkstemp and
> realpath, it checks for these in configure.  I have not passed through
> configure yet, so I cannot tell what they are really used for.

Most portable programs either supply replacements for functions that
are missing on the system, or have code to work around the missing
functionalities.

So I suggest to look in the sources for whether these functions are
really necessary, or just "nice to have".  Or just configure and try
building, and see if you get any error messages.  There are good
chances that there's no problem, even though some functions are
missing.

> However, let me say that mkstemp is indispensable in most programs—and
> Microsoft Windows is notorious for its poor support for temporary files.

As long as you need to build a Windows executable, the functionality
available on Windows is a given.  If you arrive at the conclusion that
you must have mkstemp etc., you can always write your own, or copy one
of the existing implementation on the Internet.  That's what I do when
I don't want to lose features in a ported program.


------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

krzysztof.zelechowski
I cannot configure without the functions that the configure program
explicitly requires.
It seems easier to provide replacements for two trivial functions in MinGW
missing from MSYS than for many more functions in MSYS missing from MinGW,
so for the time being I decided to build for MSYS.
I still do not get why both environments cannot have all of them but I do
realise that is your peculiar way of building things and I have to live with
that.
Thanks,
Chris

Użytkownik "Eli Zaretskii"  napisał w wiadomości grup
dyskusyjnych:[hidden email]...

> From: <[hidden email]>
> Date: Sat, 9 Aug 2014 13:31:13 +0200
>
> I do not know why the program I am trying to build needs mkstemp and
> realpath, it checks for these in configure.  I have not passed through
> configure yet, so I cannot tell what they are really used for.

Most portable programs either supply replacements for functions that
are missing on the system, or have code to work around the missing
functionalities.

So I suggest to look in the sources for whether these functions are
really necessary, or just "nice to have".  Or just configure and try
building, and see if you get any error messages.  There are good
chances that there's no problem, even though some functions are
missing.

> However, let me say that mkstemp is indispensable in most programs—and
> Microsoft Windows is notorious for its poor support for temporary files.

As long as you need to build a Windows executable, the functionality
available on Windows is a given.  If you arrive at the conclusion that
you must have mkstemp etc., you can always write your own, or copy one
of the existing implementation on the Internet.  That's what I do when
I don't want to lose features in a ported program.


------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette
may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe



------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

Eli Zaretskii
> From: <[hidden email]>
> Date: Sat, 9 Aug 2014 14:24:31 +0200
>
> I cannot configure without the functions that the configure program
> explicitly requires.

You mean, the configure script aborts saying that these functions are
required?

What package is that?

> It seems easier to provide replacements for two trivial functions in MinGW
> missing from MSYS than for many more functions in MSYS missing from MinGW,
> so for the time being I decided to build for MSYS.

OK, but then I suggest to remove the MinGW installation, so that it
doesn't trip you due to identical file names etc.

> I still do not get why both environments cannot have all of them

MSYS started as a fork of Cygwin, which already provided these
functions in its library.  While Cygwin provides its own libraries
developed by the Cygwin project, MinGW uses the runtime libraries
provided with MS-Windows, which don't have those functions.  Since no
one wrote them and submitted them for inclusion in MinGW, MinGW
doesn't have them yet.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

Keith Marshall
In reply to this post by krzysztof.zelechowski
On 09/08/14 13:24, [hidden email] wrote:
> I cannot configure without the functions that the configure program
> explicitly requires.

Why not?  It is conventional that, when configure detects a missing
function, it arranges for the application to do one of two things:

1) Configure the application to be compiled in a manner which obviates
the requirement for that function, or

2) Provide its own replacement implementation of that function.

If your application is doing neither, then it is your bug; IOW you need
to put in some effort to attain one of these alternatives.

> It seems easier to provide replacements for two trivial functions in MinGW
> missing from MSYS than for many more functions in MSYS missing from MinGW,
> so for the time being I decided to build for MSYS.

If you're leaning that way, then perhaps you should rather consider
building for Cygwin.  MSYS is a minimal fork of Cygwin-1.3, with a
strictly defined set of objectives, which are already satisfied; we
(MinGW.org) do not wish to see MSYS grow into yet another Cygwin.

Of course, you are completely at liberty to create your own Cygwin fork,
based on MSYS, to support your own development efforts, but then your
fork would no longer be MSYS.

> I still do not get why both environments cannot have all ...

Quite simply, because we do not wish MSYS to be abused in the manner in
which you seem to wish to take it; to meet your apparent development
objectives, if pure MinGW doesn't suffice, we would prefer you to use
Cygwin -- we are not in the business of competing with them.

--
Regards,
Keith.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

krzysztof.zelechowski
In reply to this post by Eli Zaretskii
I cannot remove MinGW because I actually need -lmsvcrt because MSYS provides
neither strtoull or _strtoui64.
With all respect, basename is in libiberty and dirname is in libmingwex
(although it must be recompiled for MSYS), so there is no need to write
either function, although both must be fixed by removing the unnecessary
header dependency as described.

Best regards,
Chris

Użytkownik "Eli Zaretskii"  napisał w wiadomości grup
dyskusyjnych:[hidden email]...

> From: <[hidden email]>
> Date: Sat, 9 Aug 2014 14:24:31 +0200
>
> I cannot configure without the functions that the configure program
> explicitly requires.

You mean, the configure script aborts saying that these functions are
required?

What package is that?

> It seems easier to provide replacements for two trivial functions in MinGW
> missing from MSYS than for many more functions in MSYS missing from MinGW,
> so for the time being I decided to build for MSYS.

OK, but then I suggest to remove the MinGW installation, so that it
doesn't trip you due to identical file names etc.

> I still do not get why both environments cannot have all of them

MSYS started as a fork of Cygwin, which already provided these
functions in its library.  While Cygwin provides its own libraries
developed by the Cygwin project, MinGW uses the runtime libraries
provided with MS-Windows, which don't have those functions.  Since no
one wrote them and submitted them for inclusion in MinGW, MinGW
doesn't have them yet.



------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

Keith Marshall
In reply to this post by krzysztof.zelechowski
On 08/08/14 23:14, [hidden email] wrote:
> Basename and dirname from libmingwex are easily portable to MSYS;

That may be so, but why would we do that?  MSYS doesn't need them.

> all you have to do is to remove the unnecessary inclusion.

You keep claiming that there is an unnecessary header dependency, yet
you continue to lack the courage of your conviction, to actually name
it!  While this status quo prevails, I do not believe you.

--
Regards,
Keith.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

krzysztof.zelechowski
#if 0
#include <libgen.h>
#endif


Użytkownik "Keith Marshall"  napisał w wiadomości grup
dyskusyjnych:[hidden email]...

On 08/08/14 23:14,
[hidden email] wrote:
> Basename and dirname from libmingwex are easily portable to MSYS;

That may be so, but why would we do that?  MSYS doesn't need them.

> all you have to do is to remove the unnecessary inclusion.

You keep claiming that there is an unnecessary header dependency, yet
you continue to lack the courage of your conviction, to actually name
it!  While this status quo prevails, I do not believe you.

--
Regards,
Keith.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette
may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also:
mailto:[hidden email]?subject=unsubscribe



------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

krzysztof.zelechowski
In reply to this post by Keith Marshall
The functions dirname and basename are actually required to have the tools
dirname and basename which belong to the set of objectives.  Not putting the
corresponding functions in libmsys so that everyone else can use them is a
bad design decision and moving them to libmsys would not make MSYS another
Cygwin.

Dixi.
Chris

Użytkownik "Keith Marshall"  napisał w wiadomości grup
dyskusyjnych:[hidden email]...

> It seems easier to provide replacements for two trivial functions in MinGW
> missing from MSYS than for many more functions in MSYS missing from MinGW,
> so for the time being I decided to build for MSYS.

If you're leaning that way, then perhaps you should rather consider
building for Cygwin.  MSYS is a minimal fork of Cygwin-1.3, with a
strictly defined set of objectives, which are already satisfied; we
(MinGW.org) do not wish to see MSYS grow into yet another Cygwin.

Of course, you are completely at liberty to create your own Cygwin fork,
based on MSYS, to support your own development efforts, but then your
fork would no longer be MSYS.

> I still do not get why both environments cannot have all ...

Quite simply, because we do not wish MSYS to be abused in the manner in
which you seem to wish to take it; to meet your apparent development
objectives, if pure MinGW doesn't suffice, we would prefer you to use
Cygwin -- we are not in the business of competing with them.

--
Regards,
Keith.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette
may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also:
mailto:[hidden email]?subject=unsubscribe



------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

Keith Marshall
In reply to this post by krzysztof.zelechowski
On 09/08/14 22:27, [hidden email] wrote:
> #if 0
> #include <libgen.h>
> #endif

Absolutely not!  POSIX demands that libgen.h be included, for either of
basename(3) or dirname(3).  Since both functions are included in MinGW
*exclusively* as POSIX compatibility extensions, it would be completely
wrong for these to not require inclusion of libgen.h

Perhaps you should RTFM:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/dirname.html

So no, this is *not* an unnecessary inclusion, as you claim.  On the
contrary, failure to include it would be an application bug.

--
Regards,
Keith.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

Keith Marshall
In reply to this post by krzysztof.zelechowski
On 09/08/14 22:38, [hidden email] wrote:
> The functions dirname and basename are actually required to have the tools
> dirname and basename which belong to the set of objectives.

Really?  Then how come both tools work, without needing the functions to
be exposed in the core library?

Perhaps you are a reincarnation of Private Pike, and Captain
Mainwaring's description is apt.

--
Regards,
Keith.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

krzysztof.zelechowski
The tools basename and dirname work because they have the corresponding API
functions implemented internally (actually inline).  This is a bad decision.
Chris

Użytkownik "Keith Marshall"  napisał w wiadomości grup
dyskusyjnych:[hidden email]...

On 09/08/14 22:38,
[hidden email] wrote:
> The functions dirname and basename are actually required to have the tools
> dirname and basename which belong to the set of objectives.

Really?  Then how come both tools work, without needing the functions to
be exposed in the core library?

Perhaps you are a reincarnation of Private Pike, and Captain
Mainwaring's description is apt.

--
Regards,
Keith.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette
may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also:
mailto:[hidden email]?subject=unsubscribe



------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: The situation with chown and dirname

krzysztof.zelechowski
In reply to this post by Keith Marshall
So, if you decided to move dirname and basename API to libmsys where they
should naturally go then you would have to provide libgen.h for MSYS, which
you do not want to do because of what?  You even do not need to strip it
because it contains exactly those two declarations (phew, what a waste of
header namespace!)
Providing it would make MSYS internally consistent without making it another
Cygwin.

IMHO,
Chris

Użytkownik "Keith Marshall"  napisał w wiadomości grup
dyskusyjnych:[hidden email]...

On 09/08/14 22:27,
[hidden email] wrote:
> #if 0
> #include <libgen.h>
> #endif

Absolutely not!  POSIX demands that libgen.h be included, for either of
basename(3) or dirname(3).  Since both functions are included in MinGW
*exclusively* as POSIX compatibility extensions, it would be completely
wrong for these to not require inclusion of libgen.h

Perhaps you should RTFM:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/dirname.html

So no, this is *not* an unnecessary inclusion, as you claim.  On the
contrary, failure to include it would be an application bug.

--
Regards,
Keith.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette
may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also:
mailto:[hidden email]?subject=unsubscribe



------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
12