2015-06-23 10:18 GMT+02:00 Ruben Van Boxem vanboxem.ru...@gmail.com:
2015-06-23 9:31 GMT+02:00 Alexpux alex...@gmail.com:
23 июня 2015 г., в 10:22, Ruben Van Boxem vanboxem.ru...@gmail.com
написал(а):
2015-06-23 2:17 GMT+02:00 Óscar Fuentes o...@wanadoo.es:
So moving cc1plus.exe to
2015-06-23 2:17 GMT+02:00 Óscar Fuentes o...@wanadoo.es:
So moving cc1plus.exe to `bin' makes the toolchain self contained, but
it is no solution as soon as you try to execute the programs you created
with that toolchain.
Let me just jump in here and add an extra data point to the
2015-06-23 9:31 GMT+02:00 Alexpux alex...@gmail.com:
23 июня 2015 г., в 10:22, Ruben Van Boxem vanboxem.ru...@gmail.com
написал(а):
2015-06-23 2:17 GMT+02:00 Óscar Fuentes o...@wanadoo.es:
So moving cc1plus.exe to `bin' makes the toolchain self contained, but
it is no solution as soon
23 июня 2015 г., в 10:22, Ruben Van Boxem vanboxem.ru...@gmail.com
написал(а):
2015-06-23 2:17 GMT+02:00 Óscar Fuentes o...@wanadoo.es
mailto:o...@wanadoo.es:
So moving cc1plus.exe to `bin' makes the toolchain self contained, but
it is no solution as soon as you try to execute the
Edward Diener eldlistmaili...@tropicsoft.com
writes:
Apparently those programmers are not so inconvenienced as you are by
having to use methods like the .bat mentioned above. And I can assure
you that some of those programmers have quite a few gcc installs on
their machines, that they use on
On 6/21/2015 10:43 PM, Óscar Fuentes wrote:
Edward Diener eldlistmaili...@tropicsoft.com
writes:
At the end, adapting your PATH setting works the best. Just a simple
.bat file solves the problem for those of us that need to constantly
experiment with multiple installs:
@rem
On 6/22/2015 4:50 PM, Óscar Fuentes wrote:
Edward Diener eldlistmaili...@tropicsoft.com
writes:
As I mentioned on other message on this thread, you must set PATH
anyways for executing the resulting binaries of your compilation. There
is no possible workaround for this, other than installing
On 6/22/2015 8:17 PM, Óscar Fuentes wrote:
Edward Diener eldlistmaili...@tropicsoft.com
writes:
Maybe your frustration does not allow you to understand what I wrote.
Please read it again. I expect some difficulty with the concept of
having multiple installs of the toolset, with varying
JonY jo...@users.sourceforge.net writes:
This. This is the reason why it was never changed, because it was never
seen as a problem, its just something you did.
I setup PATH depending on which compiler version I want to use, all
sharing the same mingw-w64 install, courtesy of hardcoded paths.
On 6/22/2015 10:43, Óscar Fuentes wrote:
I am surprised that such good programmers should understand so little
about producing a self-enclosed installation of mingw-64 ( or mingw ) to
the point of not being able to create a distribution that just works
automatically when any executable,
Edward,
I'm really flashed about the enormous patience and tolerance from this
community.
However, you may or may not noticed, that there are different builds with
configurations for mingw-w64 based toolchains available.
What you need for your purpose is a toolchain that is based on statically
On 6/22/2015 12:02 PM, Óscar Fuentes wrote:
Edward Diener eldlistmaili...@tropicsoft.com
writes:
Apparently those programmers are not so inconvenienced as you are by
having to use methods like the .bat mentioned above. And I can assure
you that some of those programmers have quite a few gcc
I still get errors because libwinpthread-1.dll cannot be found even
The system PATH needs to include the directory where these DLLs are or you
can copy them to the directory where the compiled application resides.
2015-06-21 18:28 GMT+03:00 Edward Diener eldlistmaili...@tropicsoft.com:
On
On 6/21/2015 7:45 AM, LRN wrote:
On 21.06.2015 5:44, John E. / TDM wrote:
On 6/20/2015 8:25 PM, Edward Diener wrote:
Any timeframe for a gcc 5.1 release ? I noticed the latest mingw-64
install now has gcc-5.1, but it has the same hardcoded to c:\mingw
limitation which my OP is about.
My
On 21.06.2015 5:44, John E. / TDM wrote:
On 6/20/2015 8:25 PM, Edward Diener wrote:
Any timeframe for a gcc 5.1 release ? I noticed the latest mingw-64
install now has gcc-5.1, but it has the same hardcoded to c:\mingw
limitation which my OP is about.
My experience in the past with other
On 21.06.2015 18:56, Edward Diener wrote:
On 6/21/2015 7:45 AM, LRN wrote:
On 21.06.2015 5:44, John E. / TDM wrote:
On 6/20/2015 8:25 PM, Edward Diener wrote:
Any timeframe for a gcc 5.1 release ? I noticed the latest mingw-64
install now has gcc-5.1, but it has the same hardcoded to c:\mingw
On 6/21/2015 12:03 PM, Yaron Keren wrote:
I still get errors because libwinpthread-1.dll cannot be found even
The system PATH needs to include the directory where these DLLs are or
you can copy them to the directory where the compiled application resides.
I appreciate the free mingw-64
On 6/21/2015 2:28 AM, Yaron Keren wrote:
The mingw-builds distro uses relative paths had worked well in any
install location for the past two years at least.
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/
It also includes the
On 6/21/2015 09:32, Edward Diener wrote:
Furthermore, GCC typically comes with a distro's package manager (which
is expected to install to a fixed location) or built from source (with
the sysroot derived from the configure arguments). Neither has any
issues with hardcoded paths.
Only on
Yaron Keren yaron.ke...@gmail.com
writes:
Why in the world should I have to put anything in my PATH if these
releases are self-enclosed ? I am executing gcc from the exact same
directory where the libwinpthread-1.dll exists.
I misunderstood you, thought you refer to running compiled apps not
Edward Diener eldlistmaili...@tropicsoft.com
writes:
At the end, adapting your PATH setting works the best. Just a simple
.bat file solves the problem for those of us that need to constantly
experiment with multiple installs:
@rem mingw-w64-492.bat
@PATH=path-to-the-bin-directory;%PATH%
Why in the world should I have to put anything in my PATH if these
releases are self-enclosed ? I am executing gcc from the exact same
directory where the libwinpthread-1.dll exists.
I misunderstood you, thought you refer to running compiled apps not gcc.
It's very convenient to have the gcc bin
The mingw-builds distro uses relative paths had worked well in any install
location for the past two years at least.
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/
It also includes the absolute path of the build original location
Why does mingw-64, or the original mingw for that matter, consistently
hardcode include and lib search paths in their build for c:\mingw
instead of searching for include files and libraries relative to its
installation structure ?
Hardcoding absolute paths makes it so much harder running
On 6/20/2015 10:50 AM, LRN wrote:
On 20.06.2015 17:43, Edward Diener wrote:
Why does mingw-64, or the original mingw for that matter, consistently
hardcode include and lib search paths in their build for c:\mingw
instead of searching for include files and libraries relative to its
On 20.06.2015 19:21, Edward Diener wrote:
On 6/20/2015 10:50 AM, LRN wrote:
On 20.06.2015 17:43, Edward Diener wrote:
Why does mingw-64, or the original mingw for that matter, consistently
hardcode include and lib search paths in their build for c:\mingw
instead of searching for include files
On 6/20/2015 5:08 PM, LRN wrote:
On 20.06.2015 19:21, Edward Diener wrote:
On 6/20/2015 10:50 AM, LRN wrote:
On 20.06.2015 17:43, Edward Diener wrote:
Why does mingw-64, or the original mingw for that matter, consistently
hardcode include and lib search paths in their build for c:\mingw
On 6/20/2015 7:30 PM, Edward Diener wrote:
But you are creating a product for Windows in which the entire product,
including the gcc compiler, standard C library, standard C++ library,
and whatever other tools are entailed in a mingw-64 release, are all
part of any mingw-64 distribution. That
On 6/20/2015 9:38 PM, John E. / TDM wrote:
On 6/20/2015 7:30 PM, Edward Diener wrote:
But you are creating a product for Windows in which the entire product,
including the gcc compiler, standard C library, standard C++ library,
and whatever other tools are entailed in a mingw-64 release, are
On 6/20/2015 8:25 PM, Edward Diener wrote:
Thanks ! I will look at your toolchains. I assume if all paths are
relative there is no need for any installation to go into or have a
symbolic link from c:\mingw.
Correct.
Any timeframe for a gcc 5.1 release ? I noticed the latest mingw-64
install
On 6/20/2015 7:52 PM, JonY wrote:
On 6/21/2015 05:08, LRN wrote:
On 20.06.2015 19:21, Edward Diener wrote:
On 6/20/2015 10:50 AM, LRN wrote:
On 20.06.2015 17:43, Edward Diener wrote:
Why does mingw-64, or the original mingw for that matter, consistently
hardcode include and lib search paths
On 6/21/2015 05:08, LRN wrote:
On 20.06.2015 19:21, Edward Diener wrote:
On 6/20/2015 10:50 AM, LRN wrote:
On 20.06.2015 17:43, Edward Diener wrote:
Why does mingw-64, or the original mingw for that matter, consistently
hardcode include and lib search paths in their build for c:\mingw
32 matches
Mail list logo
