Why program in MSYS depends upon msys-1.0.dll

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

Why program in MSYS depends upon msys-1.0.dll

Varun Agrawal
Hi,

I am learning more about MinGW and I have a question regarding it.
MinGW compiled programs are supposed to run native without POSIX
emulation. So why all programs in msys package depends upon
"msys-1.0.dll"? The file description says "POSIX Emulation DLL".
Shouldn't they work without any external DLL?

Regards
Varun Agrawal

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
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: Why program in MSYS depends upon msys-1.0.dll

Eli Zaretskii
> Date: Sun, 5 Jul 2015 04:05:52 +0530
> From: Varun Agrawal <[hidden email]>
>
> I am learning more about MinGW and I have a question regarding it.
> MinGW compiled programs are supposed to run native without POSIX
> emulation. So why all programs in msys package depends upon
> "msys-1.0.dll"?

They don't.  Those that do are MSYS programs, not MinGW programs.

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
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: Why program in MSYS depends upon msys-1.0.dll

Peter Rockett
On 05/07/15 03:41, Eli Zaretskii wrote:
>> Date: Sun, 5 Jul 2015 04:05:52 +0530
>> From: Varun Agrawal <[hidden email]>
>>
>> I am learning more about MinGW and I have a question regarding it.
>> MinGW compiled programs are supposed to run native without POSIX
>> emulation. So why all programs in msys package depends upon
>> "msys-1.0.dll"?
> They don't.  Those that do are MSYS programs, not MinGW programs.
I think a slightly more expansive response to the OP is appropriate
here. The MinGW project  is not just "a compiler" - it comprises two
related components: a Windows port of the GCC toolchain, and MSYS. The
latter offers a BASH shell and a set of POSIX tools, and exists in a
separate tree. So the compiler you want to use to build your own stuff
is provided in the GCC toolchain tree. MSYS you just use as you would a
normal BASH shell. Curiously, there is a separate, ancient (v3.4.5)
version of the GCC compiler in the MSYS tree, but this, AFAIU, is only
meant to be used for building components in the MSYS sub-system, not for
general use. All the stuff in the MSYS tree depends on the msys-... DLL,
but this is only intended for use by a developer, not the end-user of
any programs generated with the GCC toolchain part.

I don't think this 'architecture' is immediately obvious to anybody
coming to MinGW for the first time.

Hope this helps the OP.

P.



------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
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: Why program in MSYS depends upon msys-1.0.dll

Alan W. Irwin
On 2015-07-05 11:04+0100 Peter Rockett wrote:

> On 05/07/15 03:41, Eli Zaretskii wrote:
>>> Date: Sun, 5 Jul 2015 04:05:52 +0530
>>> From: Varun Agrawal <[hidden email]>
>>>
>>> I am learning more about MinGW and I have a question regarding it.
>>> MinGW compiled programs are supposed to run native without POSIX
>>> emulation. So why all programs in msys package depends upon
>>> "msys-1.0.dll"?
>> They don't.  Those that do are MSYS programs, not MinGW programs.
> I think a slightly more expansive response to the OP is appropriate
> here. The MinGW project  is not just "a compiler" - it comprises two
> related components: a Windows port of the GCC toolchain, and MSYS. The
> latter offers a BASH shell and a set of POSIX tools, and exists in a
> separate tree. So the compiler you want to use to build your own stuff
> is provided in the GCC toolchain tree. MSYS you just use as you would a
> normal BASH shell. Curiously, there is a separate, ancient (v3.4.5)
> version of the GCC compiler in the MSYS tree, but this, AFAIU, is only
> meant to be used for building components in the MSYS sub-system, not for
> general use. All the stuff in the MSYS tree depends on the msys-... DLL,
> but this is only intended for use by a developer, not the end-user of
> any programs generated with the GCC toolchain part.
>
> I don't think this 'architecture' is immediately obvious to anybody
> coming to MinGW for the first time.

Would someone be willing to expand a bit further to satisfy my
curiousity about this interesting topic?

The MinGW part of MinGW/MSYS includes, e.g.,

MinGW-4.7.2/bin/mingw32-make.exe

while the MSYS part of MinGW/MSYS includes

MinGW-4.7.2/msys/1.0/bin/make.exe

For CMake-based build systems, if you put MinGW-4.7.2/bin on the PATH
and keep MinGW-4.7.2/msys/1.0/bin _off_ the PATH then you can use the
"MinGW Makefiles" CMake generator and mingw32-make.exe to build
executables for a project.  Alternatively, you can put both locations
on the PATH, and use the "MSYS Makefiles" CMake generator and make.exe
to build executables for a project.

In the "MinGW Makefiles" case I assume those executables are not
linked in any way to msys-1.0.dll, but in the "MSYS Makefiles" case I
assume they are linked to msys-1.0.dll.

Can somebody confirm those assumptions?  Also, can somebody help with
the appropriate options for either readelf or objdump to discover what
libraries are linked to an executable?  I can never remember the exact
syntax of those commands since it has been a long time since I used
them last, but I am sure one or the other or both could give the
definitive answer.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
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: Why program in MSYS depends upon msys-1.0.dll

Eli Zaretskii
> Date: Sun, 5 Jul 2015 12:20:20 -0700 (PDT)
> From: "Alan W. Irwin" <[hidden email]>
>
> The MinGW part of MinGW/MSYS includes, e.g.,
>
> MinGW-4.7.2/bin/mingw32-make.exe
>
> while the MSYS part of MinGW/MSYS includes
>
> MinGW-4.7.2/msys/1.0/bin/make.exe

Yes.

> For CMake-based build systems, if you put MinGW-4.7.2/bin on the PATH
> and keep MinGW-4.7.2/msys/1.0/bin _off_ the PATH then you can use the
> "MinGW Makefiles" CMake generator and mingw32-make.exe to build
> executables for a project.  Alternatively, you can put both locations
> on the PATH, and use the "MSYS Makefiles" CMake generator and make.exe
> to build executables for a project.

In general, I recommend to have MinGW on MSYS's PATH, but not the
other way around.

> In the "MinGW Makefiles" case I assume those executables are not
> linked in any way to msys-1.0.dll, but in the "MSYS Makefiles" case I
> assume they are linked to msys-1.0.dll.

Yes.

> Can somebody confirm those assumptions?

Done.

> Also, can somebody help with the appropriate options for either
> readelf or objdump to discover what libraries are linked to an
> executable?

objdump -x xyzzy.exe | fgrep -I "dll name:"

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
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: Why program in MSYS depends upon msys-1.0.dll

Keith Marshall-3
On 05/07/15 21:34, Eli Zaretskii wrote:
>> In the "MinGW Makefiles" case I assume those executables are not
>> linked in any way to msys-1.0.dll, but in the "MSYS Makefiles" case I
>> assume they are linked to msys-1.0.dll.
>
> Yes.

The former assumption, definitely "yes"; the latter I'm not so sure.
I've never found CMake to be even remotely useful to me, but I always
thought that its "MSYS Makefiles" option simply assumed the presence of
the MSYS tools, so generating makefiles for use with its make.exe, but
just as we might use an MSYS hosted environment to build pure MinGW
applications, also using that MSYS make.exe but with no dependence on
msys-1.0.dll whatsoever, in the application being built, AIUI, CMake's
"MSYS Makefiles" option implies no such thing.

--
Regards,
Keith.

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
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: Why program in MSYS depends upon msys-1.0.dll

Alan W. Irwin
On 2015-07-05 22:01+0100 Keith Marshall wrote:

> On 05/07/15 21:34, Eli Zaretskii wrote:
>>> In the "MinGW Makefiles" case I assume those executables are not
>>> linked in any way to msys-1.0.dll, but in the "MSYS Makefiles" case I
>>> assume they are linked to msys-1.0.dll.
>>
>> Yes.
>
> The former assumption, definitely "yes"; the latter I'm not so sure.

Hi Keith:

It turns out you were absolutely right to doubt that assumption.
Thanks to Eli's previous response I was able to find out for sure using
objdump.  For an "MSYS Makefiles" build I have the following results.

bash.exe-3.1$ objdump -x \
epa_build/Source/comprehensive_test_disposeable/shared/build_tree/dll/libplplot.dll \
|fgrep -i "dll name:"
         DLL Name: libcsirocsa.dll
         DLL Name: libcsironn.dll
         DLL Name: libqsastime.dll
         DLL Name: libshp.dll
         DLL Name: KERNEL32.dll
         DLL Name: msvcrt.dll
         DLL Name: msvcrt.dll

i.e., no mention of msys-1.0.dll.  So it appears that in all
circumstances the CMake-based approach to configuring software builds
gives results that do not depend on msys-1.0.dll which is really
good to know.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
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
|

Usefulness of CMake

Alan W. Irwin
In reply to this post by Keith Marshall-3
On 2015-07-05 22:01+0100 Keith Marshall wrote:

> I've never found CMake to be even remotely useful to me[....]

Hi Keith:

Fair enough, but CMake is so useful to me I thought I should answer
your comment under an appropriate new subject line.  I assume you are
already aware of the arguments for CMake-based build systems and have
rejected them for your own needs so this comment is largely for the
benefit of those lurking on this mailing list who were considering the
possibility of using CMake who might be put off by the above comment.

Virtually every software project (unless extremely simple) requires a
build system to configure the build (e.g., configure needed build
files with information that is relevant to the local build system).
Older free software projects tend to have autotools-based build
systems.  ("autotools" stands for the combination of autoconf,
automake, and libtool which are used to configure a shell script
called "configure" that in turn is used to configure a make-based
build.

However, it appears from looking at the huge traffic on the cmake and
cmake-devel mailing lists that many developers of free software
projects (e.g., PLplot) have decided to move from autotools-based to a
CMake-based build system in the last decade or so for wide variety of
reasons. I won't speak for the others, but in the PLplot case, CMake
just satisfied our complex cross-platform build system and testing
needs a lot better than autotools.  Once we decided to give it a try
(initially simply as an experiment where we had no idea of how quickly
it would affect our subsequent development) we discovered that CMake
logic is easy to learn and maintain; the CMake language is powerful
for expressing build configuration needs; the various CMake generators
give access to a wide variety of different build tool possibilities
including make but also many more (such as nmake, jom, ninja, and a
wide variety of IDE's); the resulting configuration of whatever build
backend you choose to use is very fast, and the actual build after
that configuration is fast as well.

Roughly two months after we first tried CMake we found a number of our
developers who had previously stayed away from working on our
autotools-based build system were actively helping with developing our
CMake-based build system.  In fact, our CMake-based build system had
matured so quickly at that point due to all that help that it was
already doing better than our autotools-based build system which a
small subset of our developers (including me) had been maintaining for
many years prior to that. So after a release where we supported both
build systems, we completely dropped the autotools-based build system,
and our developers have never regretted that decision.

I don't want to overadvocate CMake so to add some quick caveats, other
modern alternatives to CMake exist such as SCons, and, of course,
other software projects may have different build system requirements
than the requirements of the PLplot build system. Furthermore, if
autotools already satisfies your build-system needs for some old
project that is not being actively developed, there is absolutely no
reason to move to a CMake-based build system for that old project
instead.

Those caveats aside, the bottom line is so many projects (including
PLplot) have had a lot of success with CMake-based build systems that
I suggest it is worthwhile to give that approach a try for any actively
developed software project and especially for new software projects
where no investment has yet been made to support any other build
system alternative.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
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