Re: [Mingw-w64-public] User experience with mingw-w64
On 5/29/2019 4:29 PM, maxgacode wrote: Il 29/05/2019 21:16, Edward Diener ha scritto: Are you saying I have to build a mingw-w64 toolchain for a particular version of gcc on Windows in an MSYS2 environment ? Or are you saying that once MSYS2 is installed and updated, various gcc version toolchains for Windows already exist for my use ? The toolchain downloaded with pacman from the MSYS2 is including all the binaries you need to get the same toolchain you got from MINGW-64 (and much more). No compilation needed, but if you have sources for additional stuff/libraries you can compile them using the MSYS2 environment in a "unix-like" way (configure, make, make install). If you are just looking for a "newer version" of the MIGW-64 toolchain, MSYS2 has everything you need "out of the box". OK, thanks ! I can see that the MingW-W64-builds on the mingw-w64 Downloads page is probably at an end and I must choose another way to get the latest gcc on Windows distributions, so I will try MSYS2. I always thought that mingw-w64-install.exe and the MingW-W64-builds were just so convenient, so I am sorry they will not continue being so. It was probably too much work for the developer(s) who supported that methodology. Just try! ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] User experience with mingw-w64
On 5/29/2019 2:30 PM, maxgacode wrote: Il 29/05/2019 18:03, Edward Diener ha scritto: [1] https://www.msys2.org/ Are you saying that MSYS2 provides a series of gcc compiler releases on Windows that are equivalent in compiler functionality to the official gcc releases for Linux ? Edward, I had the same issue few weeks ago updating my MinGW-64 installation (Windows7/10 64 bit). I was informed in this mailing list that the maintainers of the MinGW-64 are no longer updating the binaries for the toolchain and I got the advice to look for a new GCC version in MSYS2. It was a good advice, in few minutes I was able to have a fresh toolchain installed (GCC 8.3.0 64 bit) and I'm using it with Codeblocks without any issue. First install MSYS2 msys2-x86_64-20180531.exe then run in a MSYS-64 console pacman -Syuu pacman -Syuu till no updates pacman -S base-devel pacman -S ed pacman -S python pacman -S mingw-w64-x86_64-toolchain I used the MSYS2 environment to recompile all my additional libraries wxWidgets 3.1.2 wxPdfDocument 0.9.6 GMP 6.1.2 Glpk 4.65 MPFR 4.0.2 MPC 1.1.0 GSL 2.5 JsonCpp 1.8.4 Lapack 3.8.0 Dislin 11.2.1 Zlib 1.2.11 XlsxWriter 20190409 Lib PNG 1.6.36 NLOPT 2.4.2 ZINT 2.6.3 Postgres 9.5.4 National488 17.6.0 Sqlite 3.27.2 FFTW 3.3.8 in a smooth way.and the I configured Codeblocks Believe me MSYS2 is the way to go! Which "equivalent in compiler functionality" do you need? Are you saying I have to build a mingw-w64 toolchain for a particular version of gcc on Windows in an MSYS2 environment ? Or are you saying that once MSYS2 is installed and updated, various gcc version toolchains for Windows already exist for my use ? ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] User experience with mingw-w64
On 5/29/2019 12:09 PM, niXman wrote: Edward Diener 2019-05-28 19:50: There has not been an update to MingW-W64-builds for over a year while gcc 6.5, 7.4, 8.2, 8.3, and 9.1 have been released. The mingw-w64 downloads page at https://mingw-w64.org/doku.php/download looks wildly out of date as far as latest releases are concerned. Does nobody care ? I realize I am just an end-user and not a mingw-w64 developer, but does no one of the latter actually care about these things, or has mingw-w64 just become a platform for mingw-w64 developers where end-users are no longer very important ? Hi, you can build mingw-w64 compiler yourself using official scripts: https://github.com/niXman/mingw-builds in the develop branch you can build gcc-9.1 and gcc-trunk. Have you decided to no longer offer new gcc versions as part of mingw-w64_install and mingw builds ? ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] User experience with mingw-w64
On 5/29/2019 4:30 AM, Liu Hao wrote: 在 2019/5/29 上午12:50, Edward Diener 写道: There has not been an update to MingW-W64-builds for over a year while gcc 6.5, 7.4, 8.2, 8.3, and 9.1 have been released. The mingw-w64 downloads page at https://mingw-w64.org/doku.php/download looks wildly out of date as far as latest releases are concerned. Does nobody care ? I realize I am just an end-user and not a mingw-w64 developer, but does no one of the latter actually care about these things, or has mingw-w64 just become a platform for mingw-w64 developers where end-users are no longer very important ? MSYS2 [1] has been providing a nice ecosystem with a decent package manager (pacman) and a huge number of pre-built native binary packages for both x86 and x64 since years ago. I consider it consequently unnecessary to maintain another less durable series of toolchains. [1] https://www.msys2.org/ Are you saying that MSYS2 provides a series of gcc compiler releases on Windows that are equivalent in compiler functionality to the official gcc releases for Linux ? Are you the maintainer of the MingW-W64-builds gcc for Windows distributions ? ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] User experience with mingw-w64
There has not been an update to MingW-W64-builds for over a year while gcc 6.5, 7.4, 8.2, 8.3, and 9.1 have been released. The mingw-w64 downloads page at https://mingw-w64.org/doku.php/download looks wildly out of date as far as latest releases are concerned. Does nobody care ? I realize I am just an end-user and not a mingw-w64 developer, but does no one of the latter actually care about these things, or has mingw-w64 just become a platform for mingw-w64 developers where end-users are no longer very important ? ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Updated versions for mingw-w64-install
The last version that can be downloaded using mingw-w64-install is gcc 8.1, which was released almost a year ago. In the meantime releases 8.2 and 8.3 of gcc have been released, Can we not get an update so that mingw-w64-install can download releases 8.2 an 8.3 of gcc on Windows. Gcc is the most conforming and reliable compiler for testing on Windows, so since I test a number of libraries for Boost, and program mostly on Windows, I am always happy to get the latest releases from mingw-w64. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Description of files in a mingw-w64 distribution
On 11/26/2018 10:06 AM, Earnie via Mingw-w64-public wrote:
On 11/24/2018 5:27 PM, Edward Diener wrote:
On 11/24/2018 5:18 PM, Earnie via Mingw-w64-public wrote:
On 11/24/2018 3:17 PM, Edward Diener wrote:
Is there anywhere a description of the files in a mingw-w64
distribution, with perhaps an explanation of whether any given file
is used at compile, link, run-time, and/or for some other purpose ?
What exactly are you trying to determine? If a file is used at
runtime it will be in {usr,mingw32,mingw64}/bin directory. If a file
is required for the build process you will find it in
{usr,mingw32,mingw64}/lib and perhaps under
{usr,mingw32,mingw64}/{i686,x86_64}-{pc,w64}-{msys,mingw32}/*
directories.
Yet there are many more directories in any given mingw-w64
distribution I have installed using the mingw-w64-install.exe program.
What is the purpose of those other files if they are not being used at
either compile, link, or run-time ? In other words why would a binary
distribution of mingw-w64 have files that the end-user will never use ?
Since you don't mention a list of those I cannot help you. If you wish
to be more specific maybe we can answer your query.
I was intending to be general. I just find it to be poor documentation
that the purposes of the files in a mingw-w64 distribution are not
listed/explained anywhere to the end-user. I know it is free software,
and documenting things which the programmers of free software do not
think are necessary to do so is just extra work to them, but I work with
free software also ( Boost C++ ) and usually a Boost library will
explain all the files that are publicly for use and will also mention
that in so-and-so directory are files that are used in the private
implementation of the library. A Boost library usually does not
distribute files to the end-user which has no use for the end-user when
they want to use the library to compile/link/run code. I do not know if
that is the same with mingw-w64, but since there is no documentation
outside of the use of maybe a few files concerned with compiling/linking
a library or program, I do not know if the majority of the files in the
distro are actually being used by the end-user or the documented
commands, or what those files are about. I think that mingw-w64 should
document this. I understand that it "just works", but I think that
programmers would like to know more than that about mingw-w64.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
On 11/24/2018 5:17 PM, Mateusz Mikuła wrote: Changelog for release and git version differ a lot and it won't apply cleanly. Your should get rid of Changelog part and it will work. Thanks ! After getting rid of the Changelog part and adding a few more needed packages, I finally got binutils built with the fix successfully. It did indeed fix the bug I had encountered with using clang-7.0 with a mingw-w64/gcc backend. I still do not understand the practical reason(s) for using the MSYS2 MSYS environment versus either the MSYS2 MingW 32-bit or MSYS2 MingW 64-bit environments, but I was able to succeed using the MSYS2 MSYS environment and a new binutils was produce both for mingw-w64 32-bit and mingw-w64 64-bit. I copied the files in this new binutils to my wingw-w64/gcc-8.1 32-bit and 64-bit installations respectively, and everything is working properly with both gcc-8.1 and clang-7.0. I do understand that each MSYS2 environment uses a different implementation of gcc when building software, as others explained to me, but I do not understand why some implementation of gcc should be preferred over another in MSYS2. Among my conclusions about working within MSYS2 are: 1) An environment variable, such as my initial VERSION_CONTROL, should not cause problems in the build process. Maybe only a very small subset of the user's Windows environment variables should be brought over to the MSYS2 environment to avoid such a problem. 2) I do not understand how gpg checking, which I turned off with '--skippgpcheck', works when building a package. Maybe I just needed an MSYS2 package to use gpg checking and did not have it during my attempt to build binutils. 3) Some packages with which I needed to build binutils, such as 'make' and 'texinfo', were not installed by default when I issued the 'makepkg-mingw' command. Maybe there should be some MSYS2 package which automatically installs all the software I need to build any mingw package. Thanks to all the people who helped me to get this done correctly, especially Liu Hao. I do appreciate your patient answers to my questions about the process of building a mingw package. sob., 24 lis 2018 o 22:58 Edward Diener napisał(a): On 11/24/2018 1:21 AM, Liu Hao wrote: 在 2018/11/24 13:30, Edward Diener 写道: ==> Starting prepare()... patch: invalid argument 'E:\\Programming\\VersionControl' for '$VERSION_CONTROL' Valid arguments are: - 'none', 'off' - 'simple', 'never' - 'existing', 'nil' - 'numbered', 't' ==> ERROR: A failure occurred in prepare(). Aborting... I do not know what I am doing wrong. Probably you should `unset VERSION_CONTROL` before invoking `makepkg-mingw`. OK, I got rid of the VERSION_CONTROL environment variable. Now my output is stopped with: ==> Starting prepare()... patching file configure Hunk #1 succeeded at 2956 with fuzz 1 (offset 91 lines). Hunk #2 succeeded at 2968 with fuzz 1 (offset 91 lines). patching file binutils/bucomm.c Hunk #1 succeeded at 590 with fuzz 2 (offset 15 lines). patching file binutils/elfedit.c patching file bfd/coff-alpha.c patching file bfd/coff-mips.c patching file bfd/coff-rs6000.c patching file bfd/coff-sh.c patching file bfd/coffcode.h patching file bfd/bfd-in.h Hunk #1 succeeded at 138 (offset 1 line). patching file bfd/bfd-in2.h Hunk #1 succeeded at 145 (offset 1 line). patching file binutils/dwarf.c Hunk #1 succeeded at 183 (offset 19 lines). patching file binutils/nm.c Hunk #1 succeeded at 171 (offset 1 line). Hunk #2 succeeded at 302 (offset 2 lines). patching file binutils/prdbg.c patching file binutils/readelf.c Hunk #1 succeeded at 1214 (offset 60 lines). Hunk #2 succeeded at 13255 (offset 883 lines). patching file binutils/strings.c Hunk #1 succeeded at 557 (offset -38 lines). Hunk #2 succeeded at 576 (offset -38 lines). Hunk #3 succeeded at 595 (offset -38 lines). patching file gas/as.h Hunk #1 succeeded at 437 (offset -1 lines). patching file gas/read.c Hunk #1 succeeded at 4437 (offset 22 lines). patching file gold/configure Hunk #1 succeeded at 7629 (offset 71 lines). patching file gold/configure.ac Hunk #1 succeeded at 655 (offset 20 lines). patching file include/ansidecl.h patching file ld/ChangeLog Hunk #1 succeeded at 1 with fuzz 1. patching file ld/ld.texinfo patching file ld/scripttempl/pe.sc patching file ld/scripttempl/pep.sc patching file ld/ChangeLog Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file ld/ChangeLog.rej patching file ld/scripttempl/pe.sc Hunk #1 succeeded at 159 (offset -2 lines). patching file ld/scripttempl/pep.sc Hunk #1 succeeded at 159 (offset -2 lines). ==> ERROR: A failure occurred in prepare(). Aborting... It looks like my patch is changing the ld/Changelog file in some way that is incorrect. The full patch was taken from https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=73af69e74974eaa155eec89867e3ccc77ab39f6d but it seems like the ChangeLog portion of the patc
Re: [Mingw-w64-public] Description of files in a mingw-w64 distribution
On 11/24/2018 5:18 PM, Earnie via Mingw-w64-public wrote:
On 11/24/2018 3:17 PM, Edward Diener wrote:
Is there anywhere a description of the files in a mingw-w64
distribution, with perhaps an explanation of whether any given file is
used at compile, link, run-time, and/or for some other purpose ?
What exactly are you trying to determine? If a file is used at runtime
it will be in {usr,mingw32,mingw64}/bin directory. If a file is
required for the build process you will find it in
{usr,mingw32,mingw64}/lib and perhaps under
{usr,mingw32,mingw64}/{i686,x86_64}-{pc,w64}-{msys,mingw32}/* directories.
Yet there are many more directories in any given mingw-w64 distribution
I have installed using the mingw-w64-install.exe program. What is the
purpose of those other files if they are not being used at either
compile, link, or run-time ? In other words why would a binary
distribution of mingw-w64 have files that the end-user will never use ?
You can use `pacman -Qo FILE` to determine which package a file is
related to. You can then use `pacman -Qi PACKAGE` to get a description
of the package. If a program is executable, usually add --help or
sometimes -h or perhaps -? will give a description of the executable
purpose and options.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
On 11/24/2018 1:21 AM, Liu Hao wrote: 在 2018/11/24 13:30, Edward Diener 写道: ==> Starting prepare()... patch: invalid argument 'E:\\Programming\\VersionControl' for '$VERSION_CONTROL' Valid arguments are: - 'none', 'off' - 'simple', 'never' - 'existing', 'nil' - 'numbered', 't' ==> ERROR: A failure occurred in prepare(). Aborting... I do not know what I am doing wrong. Probably you should `unset VERSION_CONTROL` before invoking `makepkg-mingw`. OK, I got rid of the VERSION_CONTROL environment variable. Now my output is stopped with: ==> Starting prepare()... patching file configure Hunk #1 succeeded at 2956 with fuzz 1 (offset 91 lines). Hunk #2 succeeded at 2968 with fuzz 1 (offset 91 lines). patching file binutils/bucomm.c Hunk #1 succeeded at 590 with fuzz 2 (offset 15 lines). patching file binutils/elfedit.c patching file bfd/coff-alpha.c patching file bfd/coff-mips.c patching file bfd/coff-rs6000.c patching file bfd/coff-sh.c patching file bfd/coffcode.h patching file bfd/bfd-in.h Hunk #1 succeeded at 138 (offset 1 line). patching file bfd/bfd-in2.h Hunk #1 succeeded at 145 (offset 1 line). patching file binutils/dwarf.c Hunk #1 succeeded at 183 (offset 19 lines). patching file binutils/nm.c Hunk #1 succeeded at 171 (offset 1 line). Hunk #2 succeeded at 302 (offset 2 lines). patching file binutils/prdbg.c patching file binutils/readelf.c Hunk #1 succeeded at 1214 (offset 60 lines). Hunk #2 succeeded at 13255 (offset 883 lines). patching file binutils/strings.c Hunk #1 succeeded at 557 (offset -38 lines). Hunk #2 succeeded at 576 (offset -38 lines). Hunk #3 succeeded at 595 (offset -38 lines). patching file gas/as.h Hunk #1 succeeded at 437 (offset -1 lines). patching file gas/read.c Hunk #1 succeeded at 4437 (offset 22 lines). patching file gold/configure Hunk #1 succeeded at 7629 (offset 71 lines). patching file gold/configure.ac Hunk #1 succeeded at 655 (offset 20 lines). patching file include/ansidecl.h patching file ld/ChangeLog Hunk #1 succeeded at 1 with fuzz 1. patching file ld/ld.texinfo patching file ld/scripttempl/pe.sc patching file ld/scripttempl/pep.sc patching file ld/ChangeLog Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file ld/ChangeLog.rej patching file ld/scripttempl/pe.sc Hunk #1 succeeded at 159 (offset -2 lines). patching file ld/scripttempl/pep.sc Hunk #1 succeeded at 159 (offset -2 lines). ==> ERROR: A failure occurred in prepare(). Aborting... It looks like my patch is changing the ld/Changelog file in some way that is incorrect. The full patch was taken from https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=73af69e74974eaa155eec89867e3ccc77ab39f6d but it seems like the ChangeLog portion of the patch is somehow incorrect. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Description of files in a mingw-w64 distribution
Is there anywhere a description of the files in a mingw-w64 distribution, with perhaps an explanation of whether any given file is used at compile, link, run-time, and/or for some other purpose ? ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
On 11/23/2018 10:04 PM, Liu Hao wrote:
在 2018/11/24 上午9:31, Edward Diener 写道:
On 11/23/2018 5:06 PM, Greg Jung wrote:
You should try "makepkg -g" and paste/copy the results, for the lines
that
are different, into the PKGBUILD.
Then, makepkg --check can be used to test it.
When I run makepkg -g I get:
==> ERROR: pkgname is not allowed to start with a hyphen.
==> ERROR: depends is not allowed to start with a hyphen.
==> ERROR: depends is not allowed to start with a hyphen.
==> ERROR: makedepends is not allowed to start with a hyphen.
==> ERROR: makedepends is not allowed to start with a hyphen.
In the PKGBUILD file I see these lines among others:
pkgname=("${MINGW_PACKAGE_PREFIX}-${_realname}")
depends=("${MINGW_PACKAGE_PREFIX}-libiconv" "${MINGW_PACKAGE_PREFIX}-zlib")
makedepends=("${MINGW_PACKAGE_PREFIX}-libiconv"
"${MINGW_PACKAGE_PREFIX}-zlib")
Needless to say I did not change any of these lines.
Use `makepkg-mingw` to build MinGW{32,64} packages, rather than
`makepkg`. That is exactly the difference.
First output:
$ makepkg-mingw --skippgpcheck -g
==> Retrieving sources...
-> Found binutils-2.30.tar.bz2
-> Found binutils-2.30.tar.bz2.sig
-> Found 0001-enable-gold-on.mingw32.patch
-> Found 0002-check-for-unusual-file-harder.patch
-> Found 0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch
-> Found 0110-binutils-mingw-gnu-print.patch
-> Found 0200-remove-provide-qualifiers.patch
-> Found binutils-gdb.git-73af69e74974eaa155eec89867e3ccc77ab39f6d.patch
==> Generating checksums for source files...
sha256sums=('efeade848067e9a03f1918b1da0d37aaffa0b0127a06b5e9236229851d9d0c09'
'SKIP'
'93296b909e1a4f9d8a4bbe2437aafa17ca565ef6642a9812b0360c05be228c9d'
'2c99345fc575c3a060d6677537f636c6c4154fac0fde508070f3b6296c1060d4'
'604e76e0f702ced493ee22aa3c1768b4776b2008a7d70ae0dd35fe5be3522141'
'0f145655d4f2aae3383e0c0269d0c47b8a7176144bf0595425fc38b7ebf53153'
'28b6d20d1f7e1f29b61bdafff452f2421b7f5b084f69c9563ec4630b1f041abd'
'e4508ea8be28da56e0285c054cbb03636b95fcbb871ba10aa181fa7788f8c8d1')
==> Retrieving sources...
-> Found binutils-2.30.tar.bz2
-> Found binutils-2.30.tar.bz2.sig
-> Found 0001-enable-gold-on.mingw32.patch
-> Found 0002-check-for-unusual-file-harder.patch
-> Found 0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch
-> Found 0110-binutils-mingw-gnu-print.patch
-> Found 0200-remove-provide-qualifiers.patch
-> Found binutils-gdb.git-73af69e74974eaa155eec89867e3ccc77ab39f6d.patch
==> Generating checksums for source files...
sha256sums=('efeade848067e9a03f1918b1da0d37aaffa0b0127a06b5e9236229851d9d0c09'
'SKIP'
'93296b909e1a4f9d8a4bbe2437aafa17ca565ef6642a9812b0360c05be228c9d'
'2c99345fc575c3a060d6677537f636c6c4154fac0fde508070f3b6296c1060d4'
'604e76e0f702ced493ee22aa3c1768b4776b2008a7d70ae0dd35fe5be3522141'
'0f145655d4f2aae3383e0c0269d0c47b8a7176144bf0595425fc38b7ebf53153'
'28b6d20d1f7e1f29b61bdafff452f2421b7f5b084f69c9563ec4630b1f041abd'
'e4508ea8be28da56e0285c054cbb03636b95fcbb871ba10aa181fa7788f8c8d1')
Second output:
$ makepkg-mingw --skippgpcheck
==> Making package: mingw-w64-binutils 2.30-5 (Sat, Nov 24, 2018
12:21:41 AM)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found binutils-2.30.tar.bz2
-> Found binutils-2.30.tar.bz2.sig
-> Found 0001-enable-gold-on.mingw32.patch
-> Found 0002-check-for-unusual-file-harder.patch
-> Found 0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch
-> Found 0110-binutils-mingw-gnu-print.patch
-> Found 0200-remove-provide-qualifiers.patch
-> Found binutils-gdb.git-73af69e74974eaa155eec89867e3ccc77ab39f6d.patch
==> WARNING: Skipping verification of source file PGP signatures.
==> Validating source files with sha256sums...
binutils-2.30.tar.bz2 ... Passed
binutils-2.30.tar.bz2.sig ... Skipped
0001-enable-gold-on.mingw32.patch ... Passed
0002-check-for-unusual-file-harder.patch ... Passed
0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch ... Passed
0110-binutils-mingw-gnu-print.patch ... Passed
0200-remove-provide-qualifiers.patch ... Passed
binutils-gdb.git-73af69e74974eaa155eec89867e3ccc77ab39f6d.patch ...
Passed
==> Extracting sources...
-> Extracting binutils-2.30.tar.bz2 with bsdtar
==> Starting prepare()...
patch: invalid argument 'E:\\Programming\\VersionControl' for
'$VERSION_CONTROL'
Valid arguments are:
- 'none', 'off'
- 'simple', 'never'
- 'existing', 'nil'
- 'numbered', 't'
==> ERROR: A failure occurred in prepare().
Aborting...
I do not know what I am doing wrong.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
On 11/23/2018 5:49 PM, Earnie via Mingw-w64-public wrote: On 11/23/2018 3:12 PM, Edward Diener wrote: On 11/23/2018 9:06 AM, Liu Hao wrote: 在 2018/11/23 21:55, Edward Diener 写道: On 11/22/2018 9:07 PM, Liu Hao wrote: ==> Verifying source file signatures with gpg... binutils-2.30.tar.bz2 ... FAILED (unknown public key 13FCEF89DD9E3C4F) ==> ERROR: One or more PGP signatures could not be verified! Do you have any idea of how I am supposed to fix the ERROR ? Passing `--skippgpcheck` to `makepkg-mingw` would likely overcome this problem. I used --skippgpcheck' but am now getting this really cryptic error of: ==> Starting prepare()... patch: invalid argument 'E:\\Programming\\VersionControl' for '$VERSION_CONTROL' Valid arguments are: - 'none', 'off' - 'simple', 'never' - 'existing', 'nil' - 'numbered', 't' ==> ERROR: A failure occurred in prepare(). Aborting... I have an environment variable under Windows called VERSION_CONTROL but what that has to do with the problem above I do not understand. Does MSYS2 look for an environment variable called VERSION_CONTROL ? It is possible, though I don't know for sure yet, that such a variable could interfere with operation of makepkg. The failure is in applying the first patch file. The patch program isn't liking the Windows style path. Add `--debug` to see the actual command line being executed. When I added --debug, as in 'makepkg-mingw --skippgpcheck --debug', I received: makepkg: invalid option '--debug' ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
On 11/23/2018 5:06 PM, Greg Jung wrote:
You should try "makepkg -g" and paste/copy the results, for the lines that
are different, into the PKGBUILD.
Then, makepkg --check can be used to test it.
When I run makepkg -g I get:
==> ERROR: pkgname is not allowed to start with a hyphen.
==> ERROR: depends is not allowed to start with a hyphen.
==> ERROR: depends is not allowed to start with a hyphen.
==> ERROR: makedepends is not allowed to start with a hyphen.
==> ERROR: makedepends is not allowed to start with a hyphen.
In the PKGBUILD file I see these lines among others:
pkgname=("${MINGW_PACKAGE_PREFIX}-${_realname}")
depends=("${MINGW_PACKAGE_PREFIX}-libiconv" "${MINGW_PACKAGE_PREFIX}-zlib")
makedepends=("${MINGW_PACKAGE_PREFIX}-libiconv"
"${MINGW_PACKAGE_PREFIX}-zlib")
Needless to say I did not change any of these lines.
On Fri, Nov 23, 2018 at 10:51 AM Edward Diener <
eldlistmaili...@tropicsoft.com> wrote:
On 11/23/2018 9:06 AM, Liu Hao wrote:
在 2018/11/23 21:55, Edward Diener 写道:
On 11/22/2018 9:07 PM, Liu Hao wrote:
==> Verifying source file signatures with gpg...
binutils-2.30.tar.bz2 ... FAILED (unknown public key
13FCEF89DD9E3C4F)
==> ERROR: One or more PGP signatures could not be verified!
Do you have any idea of how I am supposed to fix the ERROR ?
Passing `--skippgpcheck` to `makepkg-mingw` would likely overcome this
problem.
I used --skippgpcheck' but am now getting this really cryptic error of:
==> Starting prepare()...
patch: invalid argument 'E:\\Programming\\VersionControl' for
'$VERSION_CONTROL'
Valid arguments are:
- 'none', 'off'
- 'simple', 'never'
- 'existing', 'nil'
- 'numbered', 't'
==> ERROR: A failure occurred in prepare().
Aborting...
I have an environment variable under Windows called VERSION_CONTROL but
what that has to do with the problem above I do not understand. Does
MSYS2 look for an environment variable called VERSION_CONTROL ?
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
On 11/23/2018 9:06 AM, Liu Hao wrote: 在 2018/11/23 21:55, Edward Diener 写道: On 11/22/2018 9:07 PM, Liu Hao wrote: ==> Verifying source file signatures with gpg... binutils-2.30.tar.bz2 ... FAILED (unknown public key 13FCEF89DD9E3C4F) ==> ERROR: One or more PGP signatures could not be verified! Do you have any idea of how I am supposed to fix the ERROR ? Passing `--skippgpcheck` to `makepkg-mingw` would likely overcome this problem. I used --skippgpcheck' but am now getting this really cryptic error of: ==> Starting prepare()... patch: invalid argument 'E:\\Programming\\VersionControl' for '$VERSION_CONTROL' Valid arguments are: - 'none', 'off' - 'simple', 'never' - 'existing', 'nil' - 'numbered', 't' ==> ERROR: A failure occurred in prepare(). Aborting... I have an environment variable under Windows called VERSION_CONTROL but what that has to do with the problem above I do not understand. Does MSYS2 look for an environment variable called VERSION_CONTROL ? ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
On 11/22/2018 9:07 PM, Liu Hao wrote:
在 2018/11/23 上午7:50, Edward Diener 写道:
There is a bug which in binutils which causes clang targeting
mingw-64/gcc on Windows to create a bad windows executable. The bug is
explained at https://sourceware.org/bugzilla/show_bug.cgi?id=23872 and
is fixed at
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=73af69e74974eaa155eec89867e3ccc77ab39f6d
in the binutils-gdb git repository. I understand that part of the blame
for this problem resides with clang, and I have posted a bug report with
clang that is referencing the problem I found, which may be because of
the bug.
Is it possible for me to replace the binutils executables in the latest
mingw-64 installation I have installed on Windows, which is for gcc-8.1,
with the fixed version ? If so how would I do that working on Windows ?
I do have MSYS2 installed but I do not know how to use it to rebuild the
binutils for a mingw-64 installation, if that is possible, so if anyone
can offer me guidance in doing so it would be appreciated. I am a
knowledgeable C++ programmer so I just need some sort of recipe for
doing this, if it is possible, in order to succeed.
If you already have MSYS2 then upgrading its packages is easy:
1. Clone 'https://github.com/Alexpux/MINGW-packages.git'.
2. CD into 'mingw-w64-binutils', where there are a series of patches and
a file named 'PKGBUILD'.
3. Save the commit in question as a patch file.
4. Add that patch into 'PKGBUILD'. Note that there are two places where
it is expected. The checksum need not be updated.
5. Run `updpkgsums` in an MSYS2 shell to update the checksum for the new
patch.
6. Run `makepkg-mingw` in an MSYS2 shell. This builds both mingw32 and
mingw64 packages for you.
The outcome of this was:
==> Making package: mingw-w64-binutils 2.30-5 (Fri, Nov 23, 2018
8:52:01 AM)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found binutils-2.30.tar.bz2
-> Found binutils-2.30.tar.bz2.sig
-> Found 0001-enable-gold-on.mingw32.patch
-> Found 0002-check-for-unusual-file-harder.patch
-> Found 0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch
-> Found 0110-binutils-mingw-gnu-print.patch
-> Found 0200-remove-provide-qualifiers.patch
-> Found binutils-gdb.git-73af69e74974eaa155eec89867e3ccc77ab39f6d.patch
==> Validating source files with sha256sums...
binutils-2.30.tar.bz2 ... Passed
binutils-2.30.tar.bz2.sig ... Skipped
0001-enable-gold-on.mingw32.patch ... Passed
0002-check-for-unusual-file-harder.patch ... Passed
0010-bfd-Increase-_bfd_coff_max_nscns-to-65279.patch ... Passed
0110-binutils-mingw-gnu-print.patch ... Passed
0200-remove-provide-qualifiers.patch ... Passed
binutils-gdb.git-73af69e74974eaa155eec89867e3ccc77ab39f6d.patch ...
Passed
==> Verifying source file signatures with gpg...
binutils-2.30.tar.bz2 ... FAILED (unknown public key 13FCEF89DD9E3C4F)
==> ERROR: One or more PGP signatures could not be verified!
Do you have any idea of how I am supposed to fix the ERROR ?
7. Wait for the build process to finish. There should be sort of
'mingw-w64-{i686,x86_64}-binutils*.tar.xz' in the current directory
after the packages are built successfully.
8. Run `pacman -U ' to install these packages. Remember to
replace with the real names of your packages. Wildcards
are allowed.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
On 11/22/2018 10:25 PM, Greg Jung wrote:
The recipe from Liu Hao is correct for what it describes and now the
nomenclature
needs to be discussed so that you can explain what you need. You have
called something
"mingw-64" which is none of the options.
When I wrote mingw-64 I meant mingw-w64.
The MINGW group that MSYS2 uses employs the preamble, "mingw-w64" for the
native software
(i.e.. gcc.) so the 32-bit versions are called "mingw-w64-i686- and
the 64-bit versions
are called "mingw-w64-x86_64-". MSYS2 is a posix system, a subset of
CYGWIN.
In MSYS2, the directory tree /mingw64 holds native programs produced by/for
mingw-w64-x86_64,
and /mingw32 does the same, for the i686 mode. The name, "mingw32" is also
used as a generic identifier
(as for the make program, "mingw32-make" found in both /mingw64/bin and in
/mingw32/bin)
For binutils, you may have up to three versions of them. I do:
$ pacman -Ss binutils
mingw32/mingw-w64-i686-binutils 2.29.1-1 (mingw-w64-i686-toolchain)
[installed: 2.25.1-1]
A set of programs to assemble and manipulate binary and object files
(mingw-w64)
mingw64/mingw-w64-x86_64-binutils 2.29.1-1 (mingw-w64-x86_64-toolchain)
[installed: 2.25.1-1]
A set of programs to assemble and manipulate binary and object files
(mingw-w64)
msys/binutils 2.28-1 (msys2-devel) [installed: 2.25-2]
A set of programs to assemble and manipulate binary and object files
OK, the pacman -Ss binutils command gives me:
mingw32/mingw-w64-i686-binutils 2.30-5 (mingw-w64-i686-toolchain)
A set of programs to assemble and manipulate binary and object
files (mingw-w64)
mingw64/mingw-w64-x86_64-binutils 2.30-5 (mingw-w64-x86_64-toolchain)
A set of programs to assemble and manipulate binary and object
files (mingw-w64)
msys/binutils 2.30-1 (msys2-devel)
A set of programs to assemble and manipulate binary and object files
msys/mingw-w64-cross-binutils 2.30-1 (mingw-w64-cross-toolchain
mingw-w64-cross)
A set of programs to assemble and manipulate binary and object files
but the paths do not correspond to anything I can see so I assume it is
some package nomenclature.
I have installed mingw-w64 distributions under Windows and need to
update the ld.exe of one of those distributions, for gcc-8.1, so that
clang 7.0 might work. So the original answer, as I gather it, was to
build the latest mingw-w64, with the necessary patch which fixes my
problem, under MSYS2, since it appears I need a posix-like environment
to build a mingw-w64 distribution from source. My initial confusion is
whether I use the MSYS2 MSYS subsystem or one of the MSYS2 MingW
subsystems to do this, or if it even matters, so I will try the MSYS2
MSYS subsystem.
Once I do this I assume that I have produced Windows executables and
libraries and can copy the ld.exe I produce to the mingw-w64
distribution I have previously installed.
On Thu, Nov 22, 2018 at 6:49 PM Edward Diener <
eldlistmaili...@tropicsoft.com> wrote:
On 11/22/2018 9:07 PM, Liu Hao wrote:
在 2018/11/23 上午7:50, Edward Diener 写道:
There is a bug which in binutils which causes clang targeting
mingw-64/gcc on Windows to create a bad windows executable. The bug is
If you already have MSYS2 then upgrading its packages is easy:
I do not believe I am trying to upgrade an MSYS2 package. Rather I am
trying to fix a mingw-64/gcc-8.1 installation in Windows itself so that
the binutils part of the installation can be replaced by the fixed
component(s). In particular I am trying to upgrade the ld.exe in the
installation so that it performs the link correctly even for clang. I
don't mind creating another completely separate mingw-64/gcc-8.1
installation under MSYS2 which works natively under Windows if
necessary, as long as it contains the fix. Does this make any difference
in your instructions ? Also when doing things within MSYS2 am I opening
the MSYS2 MSYS prompt or am I opening the MSYS2 MingW 32-bit or MSYS2
MingW 64-bit prompts ? I am on a 64-bit machine. From what I understand
about MSYS2 the MingW 32-bit and MingW 64-bit prompts allow me to create
native Windows applications, but I do not understand the difference
between using either of the two.
1. Clone 'https://github.com/Alexpux/MINGW-packages.git'.
2. CD into 'mingw-w64-binutils', where there are a series of patches and
a file named 'PKGBUILD'.
3. Save the commit in question as a patch file.
4. Add that patch into 'PKGBUILD'. Note that there are two places where
it is expected. The checksum need not be updated.
5. Run `updpkgsums` in an MSYS2 shell to update the checksum for the new
patch.
6. Run `makepkg-mingw` in an MSYS2 shell. This builds both mingw32 and
mingw64 packages for you.
7. Wait for the build process to finish. There should be sort of
'mingw-w64-{i686,x86_64}-binutils*.tar.xz' in the current directory
after the packages are built successfully.
8. Run `pa
Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
On 11/22/2018 9:07 PM, Liu Hao wrote:
在 2018/11/23 上午7:50, Edward Diener 写道:
There is a bug which in binutils which causes clang targeting
mingw-64/gcc on Windows to create a bad windows executable. The bug is
explained at https://sourceware.org/bugzilla/show_bug.cgi?id=23872 and
is fixed at
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=73af69e74974eaa155eec89867e3ccc77ab39f6d
in the binutils-gdb git repository. I understand that part of the blame
for this problem resides with clang, and I have posted a bug report with
clang that is referencing the problem I found, which may be because of
the bug.
Is it possible for me to replace the binutils executables in the latest
mingw-64 installation I have installed on Windows, which is for gcc-8.1,
with the fixed version ? If so how would I do that working on Windows ?
I do have MSYS2 installed but I do not know how to use it to rebuild the
binutils for a mingw-64 installation, if that is possible, so if anyone
can offer me guidance in doing so it would be appreciated. I am a
knowledgeable C++ programmer so I just need some sort of recipe for
doing this, if it is possible, in order to succeed.
If you already have MSYS2 then upgrading its packages is easy:
I do not believe I am trying to upgrade an MSYS2 package. Rather I am
trying to fix a mingw-64/gcc-8.1 installation in Windows itself so that
the binutils part of the installation can be replaced by the fixed
component(s). In particular I am trying to upgrade the ld.exe in the
installation so that it performs the link correctly even for clang. I
don't mind creating another completely separate mingw-64/gcc-8.1
installation under MSYS2 which works natively under Windows if
necessary, as long as it contains the fix. Does this make any difference
in your instructions ? Also when doing things within MSYS2 am I opening
the MSYS2 MSYS prompt or am I opening the MSYS2 MingW 32-bit or MSYS2
MingW 64-bit prompts ? I am on a 64-bit machine. From what I understand
about MSYS2 the MingW 32-bit and MingW 64-bit prompts allow me to create
native Windows applications, but I do not understand the difference
between using either of the two.
1. Clone 'https://github.com/Alexpux/MINGW-packages.git'.
2. CD into 'mingw-w64-binutils', where there are a series of patches and
a file named 'PKGBUILD'.
3. Save the commit in question as a patch file.
4. Add that patch into 'PKGBUILD'. Note that there are two places where
it is expected. The checksum need not be updated.
5. Run `updpkgsums` in an MSYS2 shell to update the checksum for the new
patch.
6. Run `makepkg-mingw` in an MSYS2 shell. This builds both mingw32 and
mingw64 packages for you.
7. Wait for the build process to finish. There should be sort of
'mingw-w64-{i686,x86_64}-binutils*.tar.xz' in the current directory
after the packages are built successfully.
8. Run `pacman -U ' to install these packages. Remember to
replace with the real names of your packages. Wildcards
are allowed.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Fixing bug in binutils for mingw-64 distro
There is a bug which in binutils which causes clang targeting mingw-64/gcc on Windows to create a bad windows executable. The bug is explained at https://sourceware.org/bugzilla/show_bug.cgi?id=23872 and is fixed at https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=73af69e74974eaa155eec89867e3ccc77ab39f6d in the binutils-gdb git repository. I understand that part of the blame for this problem resides with clang, and I have posted a bug report with clang that is referencing the problem I found, which may be because of the bug. Is it possible for me to replace the binutils executables in the latest mingw-64 installation I have installed on Windows, which is for gcc-8.1, with the fixed version ? If so how would I do that working on Windows ? I do have MSYS2 installed but I do not know how to use it to rebuild the binutils for a mingw-64 installation, if that is possible, so if anyone can offer me guidance in doing so it would be appreciated. I am a knowledgeable C++ programmer so I just need some sort of recipe for doing this, if it is possible, in order to succeed. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange run-time error when using mingw-64/gcc-8.1 as clang 7.0 targeting gcc backend
On 11/21/2018 3:47 PM, Martin Storsjö wrote: On Wed, 21 Nov 2018, Edward Diener wrote: On 11/21/2018 3:26 PM, Martin Storsjö wrote: On Wed, 21 Nov 2018, Edward Diener wrote: On 11/21/2018 9:53 AM, Ozkan Sezer wrote: On 11/21/18, Edward Diener wrote: [...] Unfortunately this did not solve the problem using clang-7.0 with the gcc-8.1 backend. Most probably clang is using its own linker, rather than the mingw-64/gcc linker, and this is causing the problem. In clang-6.0 everything works properly. OK, maybe other here might be able to help. Strangely enough when I use the clang -### option to see what it is using to link my executable it shows it is using the mingw-64/gcc linker. Yes, unless your clang is built with different defaults, it defaults to use the normal linker in your environment. Yet even with the changes I made to the linker scripts, to add '. = ALIGN(4);' before the '__rt_psrelocs_start = .;' line in each script, I am seeing the original problem I reported as soon as I try to debug my problem using the mingw-64 gdb debugger. So either the linker scripts are not being used when the mingw-64/gcc linker is being used or the problem lies in some other reason. Just to be really clear, you did recompile your binutils ld linker and use the newly built copy of the executable after you changed the linker scripts right? No, I did not do that. I had a feeling that just changing the linker scripts was not enough. So how do I rebuild the linker so that it uses the changes I made to the linker scripts ? I supposed I have to be in some sort of MSYS2 environment to do this. Yes, the mingw64/msys2 environment should be good for that; running "./configure --prefix=/some/path; make; make install" in the binutils-gdb root directory should give you a ld.exe in the given path. If this ran fine you should be able to replace your normal ld.exe/x86_64-w64-mingw32-ld.exe with it. Where is the binutils-gdb root directory ? Is this from within in a mingw-w64 installation which I have already installed ? Or is this some other directory from within an MSYS2 mingw shell ? In either case what is the actual directory I have to be in to run the "./configure --prefix=/some/path; make; make install" in order to rebuild ld.exe ? // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange run-time error when using mingw-64/gcc-8.1 as clang 7.0 targeting gcc backend
On 11/21/2018 3:26 PM, Martin Storsjö wrote: On Wed, 21 Nov 2018, Edward Diener wrote: On 11/21/2018 9:53 AM, Ozkan Sezer wrote: On 11/21/18, Edward Diener wrote: [...] Unfortunately this did not solve the problem using clang-7.0 with the gcc-8.1 backend. Most probably clang is using its own linker, rather than the mingw-64/gcc linker, and this is causing the problem. In clang-6.0 everything works properly. OK, maybe other here might be able to help. Strangely enough when I use the clang -### option to see what it is using to link my executable it shows it is using the mingw-64/gcc linker. Yes, unless your clang is built with different defaults, it defaults to use the normal linker in your environment. Yet even with the changes I made to the linker scripts, to add '. = ALIGN(4);' before the '__rt_psrelocs_start = .;' line in each script, I am seeing the original problem I reported as soon as I try to debug my problem using the mingw-64 gdb debugger. So either the linker scripts are not being used when the mingw-64/gcc linker is being used or the problem lies in some other reason. Just to be really clear, you did recompile your binutils ld linker and use the newly built copy of the executable after you changed the linker scripts right? No, I did not do that. I had a feeling that just changing the linker scripts was not enough. So how do I rebuild the linker so that it uses the changes I made to the linker scripts ? I supposed I have to be in some sort of MSYS2 environment to do this. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange run-time error when using mingw-64/gcc-8.1 as clang 7.0 targeting gcc backend
On 11/21/2018 10:36 AM, Peiyuan Song wrote: Why not try https://github.com/mstorsjo/llvm-mingw, use clang with lld linker directly and libcxx c++ library. Thanks for the link. But I always thought that clang targeting mingw-64/gcc on Windows should just work as well as using mingw-64/gcc on Windows directly. The fact that it never has is always disappointing, but of course this is not the fault of mingw-64/gcc. BTW I do not think you were supposed to top-post. Edward Diener 于 2018年11月21日周三 23:17写道： On 11/21/2018 9:53 AM, Ozkan Sezer wrote: On 11/21/18, Edward Diener wrote: [...] Unfortunately this did not solve the problem using clang-7.0 with the gcc-8.1 backend. Most probably clang is using its own linker, rather than the mingw-64/gcc linker, and this is causing the problem. In clang-6.0 everything works properly. OK, maybe other here might be able to help. Strangely enough when I use the clang -### option to see what it is using to link my executable it shows it is using the mingw-64/gcc linker. Yet even with the changes I made to the linker scripts, to add '. = ALIGN(4);' before the '__rt_psrelocs_start = .;' line in each script, I am seeing the original problem I reported as soon as I try to debug my problem using the mingw-64 gdb debugger. So either the linker scripts are not being used when the mingw-64/gcc linker is being used or the problem lies in some other reason. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange run-time error when using mingw-64/gcc-8.1 as clang 7.0 targeting gcc backend
On 11/21/2018 9:53 AM, Ozkan Sezer wrote: On 11/21/18, Edward Diener wrote: [...] Unfortunately this did not solve the problem using clang-7.0 with the gcc-8.1 backend. Most probably clang is using its own linker, rather than the mingw-64/gcc linker, and this is causing the problem. In clang-6.0 everything works properly. OK, maybe other here might be able to help. Strangely enough when I use the clang -### option to see what it is using to link my executable it shows it is using the mingw-64/gcc linker. Yet even with the changes I made to the linker scripts, to add '. = ALIGN(4);' before the '__rt_psrelocs_start = .;' line in each script, I am seeing the original problem I reported as soon as I try to debug my problem using the mingw-64 gdb debugger. So either the linker scripts are not being used when the mingw-64/gcc linker is being used or the problem lies in some other reason. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange run-time error when using mingw-64/gcc-8.1 as clang 7.0 targeting gcc backend
On 11/21/2018 4:57 AM, Ozkan Sezer wrote: On 11/21/18, Edward Diener wrote: On 11/20/2018 11:55 PM, Ozkan Sezer wrote: On 11/21/18, Edward Diener wrote: On 11/20/2018 10:50 PM, Ozkan Sezer wrote: On 11/21/18, Edward Diener wrote: I am building an application using clang-7.0 targeting gcc with mingw-64/gcc-8.1 as the backend. The application shows no errors compiling or linking. When I try to debug the application I get the messages from within gdb: [New Thread 6432.0x1b38] Mingw-w64 runtime failure: Unknown pseudo relocation protocol version 65536 When building/running the same application with just mingw-64/gcc-8.1 everything works fine. I realize that this is a clang-7.0 problem and may well be that I can not use gcc-8.1 as my clang-7.0 backend for some reason. But I was wondering if anybody on the mingw-64/gcc side would have any idea what would cause the run-time error to occur ? This may be related: https://sourceware.org/bugzilla/show_bug.cgi?id=23872 If it is the case, you will need an updated binutils (or manually edit your linker scripts.) Thanks for the help. How do I get an updated binutils for mingw.w64 ? Toolchain builders will need to adopt that change and post new toolchains Where is the linker script located in a mingw.w64 distro ? It is usually at //lib/ldscripts E.g.: d:\mingw32\i686-w64-mingw32\lib\ldscripts or d:\mingw64\x86_64-w64-mingw32\lib\ldscripts For gcc-8.1 x64, let's say, there is an 'ldscripts' directory at \mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\lib\ldscripts. In that directory is a number of files starting with i386pe. and i386pep. and the comment for these are that they are linker scripts. Do I need to alter all of these or just the i386pe.x and i386pep.x files ? In each file is the line '. = ALIGN(__section_alignment__);' but I also occasionally see another '. = ALIGN(n);' line occasionally. So how do I modify the file(s) ? https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=73af69e74974eaa155eec89867e3ccc77ab39f6d I think, in all of those scripts, you should find the line (there should be only one instance of it): __rt_psrelocs_start = .; Insert the new alignment directive just before that line. Unfortunately this did not solve the problem using clang-7.0 with the gcc-8.1 backend. Most probably clang is using its own linker, rather than the mingw-64/gcc linker, and this is causing the problem. In clang-6.0 everything works properly. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange run-time error when using mingw-64/gcc-8.1 as clang 7.0 targeting gcc backend
On 11/21/2018 4:57 AM, Ozkan Sezer wrote: On 11/21/18, Edward Diener wrote: On 11/20/2018 11:55 PM, Ozkan Sezer wrote: On 11/21/18, Edward Diener wrote: On 11/20/2018 10:50 PM, Ozkan Sezer wrote: On 11/21/18, Edward Diener wrote: I am building an application using clang-7.0 targeting gcc with mingw-64/gcc-8.1 as the backend. The application shows no errors compiling or linking. When I try to debug the application I get the messages from within gdb: [New Thread 6432.0x1b38] Mingw-w64 runtime failure: Unknown pseudo relocation protocol version 65536 When building/running the same application with just mingw-64/gcc-8.1 everything works fine. I realize that this is a clang-7.0 problem and may well be that I can not use gcc-8.1 as my clang-7.0 backend for some reason. But I was wondering if anybody on the mingw-64/gcc side would have any idea what would cause the run-time error to occur ? This may be related: https://sourceware.org/bugzilla/show_bug.cgi?id=23872 If it is the case, you will need an updated binutils (or manually edit your linker scripts.) Thanks for the help. How do I get an updated binutils for mingw.w64 ? Toolchain builders will need to adopt that change and post new toolchains Where is the linker script located in a mingw.w64 distro ? It is usually at //lib/ldscripts E.g.: d:\mingw32\i686-w64-mingw32\lib\ldscripts or d:\mingw64\x86_64-w64-mingw32\lib\ldscripts For gcc-8.1 x64, let's say, there is an 'ldscripts' directory at \mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\x86_64-w64-mingw32\lib\ldscripts. In that directory is a number of files starting with i386pe. and i386pep. and the comment for these are that they are linker scripts. Do I need to alter all of these or just the i386pe.x and i386pep.x files ? In each file is the line '. = ALIGN(__section_alignment__);' but I also occasionally see another '. = ALIGN(n);' line occasionally. So how do I modify the file(s) ? https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=73af69e74974eaa155eec89867e3ccc77ab39f6d I think, in all of those scripts, you should find the line (there should be only one instance of it): __rt_psrelocs_start = .; Insert the new alignment directive just before that line. Thanks ! ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange run-time error when using mingw-64/gcc-8.1 as clang 7.0 targeting gcc backend
On 11/20/2018 10:50 PM, Ozkan Sezer wrote: On 11/21/18, Edward Diener wrote: I am building an application using clang-7.0 targeting gcc with mingw-64/gcc-8.1 as the backend. The application shows no errors compiling or linking. When I try to debug the application I get the messages from within gdb: [New Thread 6432.0x1b38] Mingw-w64 runtime failure: Unknown pseudo relocation protocol version 65536 When building/running the same application with just mingw-64/gcc-8.1 everything works fine. I realize that this is a clang-7.0 problem and may well be that I can not use gcc-8.1 as my clang-7.0 backend for some reason. But I was wondering if anybody on the mingw-64/gcc side would have any idea what would cause the run-time error to occur ? This may be related: https://sourceware.org/bugzilla/show_bug.cgi?id=23872 If it is the case, you will need an updated binutils (or manually edit your linker scripts.) Thanks for the help. How do I get an updated binutils for mingw.w64 ? Where is the linker script located in a mingw.w64 distro ? ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Strange run-time error when using mingw-64/gcc-8.1 as clang 7.0 targeting gcc backend
I am building an application using clang-7.0 targeting gcc with mingw-64/gcc-8.1 as the backend. The application shows no errors compiling or linking. When I try to debug the application I get the messages from within gdb: [New Thread 6432.0x1b38] Mingw-w64 runtime failure: Unknown pseudo relocation protocol version 65536 When building/running the same application with just mingw-64/gcc-8.1 everything works fine. I realize that this is a clang-7.0 problem and may well be that I can not use gcc-8.1 as my clang-7.0 backend for some reason. But I was wondering if anybody on the mingw-64/gcc side would have any idea what would cause the run-time error to occur ? ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc
On 5/31/2017 2:38 PM, niXman wrote: Edward Diener 2017-05-31 15:06: When you try this yourself does everything work as expected ? Sure. I have just installed MSYS2 from scratch. I've installed only git(pacman -S git), cloned the mingw-builds project, checked out to develop branch, and ran the building(./build...). In response, I received a list of packages that needed to be installed and I've installed them. I've started the build(./build ...) again and this is what I see at the moment: $ ./build --mode=gcc-7.1.0 --bootstrap --buildroot=/c/mingw710 --threads=posix --exceptions=dwarf --arch=i686 --bin-compress --jobs=2 --rev=0 --rt-version=v5 -> Checking OS bitness... 64-bit -> Checking OS type... MINGW32_NT-6.1 -> Checking for installed packages... done -> i686 toolchain --> i686 toolchain is not installed --> download i686-6.3.0-release-posix-dwarf-rt_v5-rev2.7z... done --> unpack i686-6.3.0-release-posix-dwarf-rt_v5-rev2.7z... done -> start building i686-7.1.0-posix-dwarf-rt_v5-rev0 with "c,c++,fortran" languages supported -> libiconv --> download libiconv-1.14.tar.gz... done --> unpack libiconv-1.14.tar.gz... done --> patching... done --> configure... done --> building... done --> installing... done -> zlib --> download zlib-1.2.11.tar.gz... done --> unpack zlib-1.2.11.tar.gz... done --> patching... done --> configure... done --> building... done --> installing... done -> gmp --> download gmp-6.1.0.tar.bz2... done --> unpack gmp-6.1.0.tar.bz2... done --> configure... done --> building... done --> installing... done -> mpfr --> download mpfr-3.1.4.tar.bz2... done --> unpack mpfr-3.1.4.tar.bz2... done --> configure... done --> building... done --> installing... done -> mpc --> download mpc-1.0.3.tar.gz... done --> unpack mpc-1.0.3.tar.gz... done --> configure... done --> building... done --> installing... done -> isl --> download isl-0.16.1.tar.xz... done --> unpack isl-0.16.1.tar.xz... done --> patching... done --> configure... done --> building... done --> installing... done -> mingw-w64-download --> checkout mingw-w64... Please show me the result of 'echo $PATH' cmd. $ echo $PATH /usr/local/bin:/usr/bin:/bin:/opt/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc
On 5/31/2017 12:32 AM, niXman wrote: Edward Diener 2017-05-31 07:26: Not found level for patch libiconv/0001-compile-relocatable-in-gnulib.mingw.patch, error=2 I do not understand what's going on... please exec the 'pacman -S patch' cmd and rerun building again. Same problem. I do not know what's going on either. I am just an end-user of MSYS2, but evidently something is happening which you do not expect. When you try this yourself does everything work as expected ? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc
On 5/30/2017 10:59 PM, niXman wrote: Edward Diener 2017-05-31 02:16: I now get: -> Checking for installed packages... the following packages are not installed: git,subversion,tar,zip,p7zip,make,patch,automake,autoconf,libtool,flex,bison,gettext,gettext-devel,wget,sshpass,texinfo but all the above packages are already installed. please pull and rerun again. -> start building i686-7.1.0-posix-dwarf-rt_v5-rev0 with "c,c++,fortran" languages supported -> libiconv ---> libiconv-1.14.tar.gz downloaded ---> libiconv-1.14.tar.gz unpacked --> patching... Not found level for patch libiconv/0001-compile-relocatable-in-gnulib.mingw.patch, error=2 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc
On 5/30/2017 2:45 PM, niXman wrote: Edward Diener 2017-05-30 20:43: My bad, sorry :( Fixed in the develop branch. Please pull and rerun. I now get: -> Checking for installed packages... the following packages are not installed: git,subversion,tar,zip,p7zip,make,patch,automake,autoconf,libtool,flex,bison,gettext,gettext-devel,wget,sshpass,texinfo but all the above packages are already installed. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc
On 5/30/2017 1:14 PM, niXman wrote: Edward Diener 2017-05-30 19:48: Yes. Please remove completely the mingw-builds and the c:\mingw710 directory, clone the mingw-builds again and checkout to the develop branch, and run again: ./build --mode=gcc-7.1.0 --bootstrap --buildroot=/c/mingw710 --threads=posix --exceptions=dwarf --arch=i686 --bin-compress --jobs=2 --rev=0 --rt-version=v5 The same error still occurs when I try it: ./build --mode=gcc-7.1.0 --bootstrap --buildroot=/c/mingw710 --threads=posix --exceptions=dwarf --arch=i686 --bin-compress --jobs=2 --rev=0 --rt-version=v5 -> Checking OS bitness... 64-bit -> Checking OS type... MINGW32_NT-6.3 -> Checking for installed packages... done -> i686 toolchain --> i686 toolchain is not installed --> download i686-6.3.0-release-posix-dwarf-rt_v5-rev2.7z... done --> unpack i686-6.3.0-release-posix-dwarf-rt_v5-rev2.7z... done -> start building i686-7.1.0-posix-dwarf-rt_v5-rev0 with "c,c++,fortran" languages supported -> libiconv --> download libiconv-1.14.tar.gz... done --> unpack libiconv-1.14.tar.gz... done --> patching... Not found level for patch libiconv/0001-compile-relocatable-in-gnulib.mingw.patch, error=2 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc
On 5/30/2017 12:25 PM, niXman wrote: Edward Diener 2017-05-30 18:10: I pulled the latest but the same error still occurs. Do you use the develop branch? Yes. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc
On 5/29/2017 6:28 AM, niXman wrote: Edward Diener 2017-05-29 05:26: Following instructions I eventually get under MSYS2: -> libiconv --> download libiconv-1.14.tar.gz... done --> unpack libiconv-1.14.tar.gz... done --> patching... Not found level for patch libiconv/0001-compile-relocatable-in-gnulib.mingw.patch, error=2 This is because the patch package was not installed. Fixed in develop branch. I pulled the latest but the same error still occurs. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc
On 5/28/2017 5:06 PM, niXman wrote: Edward Diener 2017-05-28 21:53: That does not seem very limiting. ELF and PE/COFF covers all popular object file formats on Linux and Windows respectively and surely just about everyone not using VC++ uses DWARF rather than sjlj. As I know, for windows targets DWARF is available only for 32bit targets.(But I can be wrong...) How would I build this above-linked libbacktrace in mingw-64 for myself ? Am I supposed to use the current mingw-64 build script to do so and just copy the aforementioned 3 files to some final directories ? 1) clone mingw-builds scripts into your home dir. 2) cd mingw-builds 3) switch to develop branch 4) ./build --mode=gcc-7.1.0 --bootstrap --buildroot=/c/mingw710 --threads=posix --exceptions=dwarf --arch=i686 --bin-compress --jobs=2 --rev=0 --rt-version=v5 Following instructions I eventually get under MSYS2: -> libiconv --> download libiconv-1.14.tar.gz... done --> unpack libiconv-1.14.tar.gz... done --> patching... Not found level for patch libiconv/0001-compile-relocatable-in-gnulib.mingw.patch, error=2 If the building of mingw-w64 in your environment is successful, I will tell you which files and where to copy to. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc
On 5/28/2017 10:15 AM, niXman wrote: Edward Diener 2017-05-28 16:32: 2) libbacktrace can be part of a mingw-64 distribution but relies on other files in that distribution ? Yes. Great ! I see in [2] below that there was a discussion of making libbacktrace standalone, but it appears that in the 4 years from that discussion that it was never followed through. I can make the libbacktrace part of the mingw-w64 distribution. In order to do this I should copy the three files(libbacktrace.a, backtrace.h, gstdint.h) from the GCC build tree. If libbacktrace were part of mingw-w64 distribution I think it would benefit mingw-64 users. This is because the new Boost stacktrace library ( I am not its author ) uses libbacktrace to produce stack trace information on demand, and I am sure you know that Boost is popular with C++ programmers. For VC++ on Windows the Boost stacktrace library uses other means to generate its stacktrace, so libbacktrace is really useful for Boost stacktrace when mingw-64 is being used. You can see Boost stacktrace at https://github.com/boostorg/stacktrace since it is now a Boost git submodule, and it should be part of the next Boost release. But pay attention to the limited possibilities of libbacktrace, the developer[1] of this library writes about: As of September 2016, libbacktrace only supports ELF and PE/COFF executables with DWARF debugging information. That does not seem very limiting. ELF and PE/COFF covers all popular object file formats on Linux and Windows respectively and surely just about everyone not using VC++ uses DWARF rather than sjlj. [1] https://github.com/ianlancetaylor/libbacktrace Thanks for the link. How would I build this above-linked libbacktrace in mingw-64 for myself ? Am I supposed to use the current mingw-64 build script to do so and just copy the aforementioned 3 files to some final directories ? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc
On 5/28/2017 3:37 AM, niXman wrote: Edward Diener 2017-05-27 23:37: Hi, Do I use msys2 in order to build libbacktrace ? When building do I need to use the version of mingw-64/gcc for which I will be using libbacktrace when I eventually use mingw-64/gcc as my compiler ? If I need to do that do I just add the mingw-64/gcc compiler to the beginning of my msys2 path ? I have used various versions of mingw-64/gcc binaries in order to test Boost libraries but I have never built another library for use by any particular version of mingw-64/gcc, which is why I am asking these questions. You can just use the mingw-builds[1] scripts that are used to build the official mingw-w64 toolchains. But the problem is yesterday I rebuild gcc-7-branch and in the logs of the builbing I can see libbacktrace has successfully builded, but not installed. In accordance with this message[2], the libbacktrace should not be installed in the destination directory because the developers find an it inner instrument of GCC. Are you essentially saying that: 1) libbacktrace can not be part of a mingw-64 distribution because it relies on gcc files which are not part of mingw-64 ? 2) libbacktrace can be part of a mingw-64 distribution but relies on other files in that distribution ? I see in [2] below that there was a discussion of making libbacktrace standalone, but it appears that in the 4 years from that discussion that it was never followed through. [1] https://github.com/niXman/mingw-builds [2] https://gcc.gnu.org/ml/gcc/2013-05/msg00174.html -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc
On 5/27/2017 12:08 PM, niXman wrote: Edward Diener 2017-05-27 18:40: On 5/26/2017 11:03 PM, Vincent Torri wrote: ./configure --host=i686-w64-mingw32 or ./configure --host=i686-w64-mingw32 for respectively 32bits and 64bits support Your configure commands are the same. ./configure --host=i686-w64-mingw32 or ./configure --host=x86_64-w64-mingw32 OK. Do I use msys2 in order to build libbacktrace ? When building do I need to use the version of mingw-64/gcc for which I will be using libbacktrace when I eventually use mingw-64/gcc as my compiler ? If I need to do that do I just add the mingw-64/gcc compiler to the beginning of my msys2 path ? I have used various versions of mingw-64/gcc binaries in order to test Boost libraries but I have never built another library for use by any particular version of mingw-64/gcc, which is why I am asking these questions. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc
On 5/26/2017 11:03 PM, Vincent Torri wrote: On Sat, May 27, 2017 at 12:14 AM, Edward Diener <eldlistmaili...@tropicsoft.com> wrote: On 5/26/2017 4:13 PM, Vincent Torri wrote: Hello On Fri, May 26, 2017 at 9:50 PM, Edward Diener <eldlistmaili...@tropicsoft.com> wrote: I would like to use a libbacktrace library for mingw-64/gcc. This is used by a new Boost library called stacktrace to provide stack traces anywhere in code in c++ when using GCC/MinGW/Clang on POSIX or Windows. Does such a library exist for mingw-64/gcc on Windows ? If not can such a library be built for a given version of mingw-64/gcc on Windows, presumably in MSYS2 ? I have written a small library and app around memory checking and PE files. It is called examine and can report backtraces (using libbfd for stack trace). It is here : https://vtorri.github.io/examine/ https://github.com/vtorri/examine I use MSYS2 + mingw-w64 for compilation, or Visual Studio. Thank you, but what does this have to do with libbacktrace for mingw-64/gcc ? you wanted a library which provide stack traces. for libbacktrace, I can see in https://github.com/gcc-mirror/gcc/tree/master/libbacktrace so PE/COFF commits and file. So I guess it is possible try autoreconf -vif and ./configure --host=i686-w64-mingw32 or ./configure --host=i686-w64-mingw32 for respectively 32bits and 64bits support Your configure commands are the same. regards Vincent regards Vincent Torri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc
On 5/26/2017 5:09 PM, Carl Kleffner wrote: drmingw <https://github.com/jrfonseca/drmingw> can be used to display post mortem information. It containes an embeddable library called ExcHndl too. Thank you, but what does this have to do with libbacktrace for mingw-64/gcc ? Regards Carl 2017-05-26 22:13 GMT+02:00 Vincent Torri <vincent.to...@gmail.com>: Hello On Fri, May 26, 2017 at 9:50 PM, Edward Diener <eldlistmaili...@tropicsoft.com> wrote: I would like to use a libbacktrace library for mingw-64/gcc. This is used by a new Boost library called stacktrace to provide stack traces anywhere in code in c++ when using GCC/MinGW/Clang on POSIX or Windows. Does such a library exist for mingw-64/gcc on Windows ? If not can such a library be built for a given version of mingw-64/gcc on Windows, presumably in MSYS2 ? I have written a small library and app around memory checking and PE files. It is called examine and can report backtraces (using libbfd for stack trace). It is here : https://vtorri.github.io/examine/ https://github.com/vtorri/examine I use MSYS2 + mingw-w64 for compilation, or Visual Studio. regards Vincent Torri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc
On 5/26/2017 4:13 PM, Vincent Torri wrote: Hello On Fri, May 26, 2017 at 9:50 PM, Edward Diener <eldlistmaili...@tropicsoft.com> wrote: I would like to use a libbacktrace library for mingw-64/gcc. This is used by a new Boost library called stacktrace to provide stack traces anywhere in code in c++ when using GCC/MinGW/Clang on POSIX or Windows. Does such a library exist for mingw-64/gcc on Windows ? If not can such a library be built for a given version of mingw-64/gcc on Windows, presumably in MSYS2 ? I have written a small library and app around memory checking and PE files. It is called examine and can report backtraces (using libbfd for stack trace). It is here : https://vtorri.github.io/examine/ https://github.com/vtorri/examine I use MSYS2 + mingw-w64 for compilation, or Visual Studio. Thank you, but what does this have to do with libbacktrace for mingw-64/gcc ? regards Vincent Torri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Is there a libbacktrace library for mingw-64/gcc
I would like to use a libbacktrace library for mingw-64/gcc. This is used by a new Boost library called stacktrace to provide stack traces anywhere in code in c++ when using GCC/MinGW/Clang on POSIX or Windows. Does such a library exist for mingw-64/gcc on Windows ? If not can such a library be built for a given version of mingw-64/gcc on Windows, presumably in MSYS2 ? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Version of libstdc++ for a given mingw-64/gcc release
On 5/19/2017 8:32 AM, niXman wrote: > Edward Diener 2017-05-19 04:05: >> How can I determine which version of libstdc++ corresponds to a >> particular release of mingw-64/gcc ? > > Hi, > > Hmm.. at the moment it's impossible... > > But you can do this: > http://stackoverflow.com/questions/10354636 > > Thanks for the link. Try adding the version information as a Windows resource for mingw-64/gcc libstdc++. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Version of libstdc++ for a given mingw-64/gcc release
How can I determine which version of libstdc++ corresponds to a particular release of mingw-64/gcc ? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Using mcfgthread instead of the gcc thread library
On 4/9/2017 11:11 AM, Liu Hao wrote: > On 2017/4/9 22:59, Edward Diener wrote: >> Are you saying that I have to build gcc-6.3 myself on Windows, rather >> than juat install it from mingw-w64-install, in order to use your library ? > Yes. However I also build it constantly, which is available here: > <https://gcc-mcf.lhmouse.com/> . > > These files, like the mingwbuilds releases, are all-in-one packages. All > binaries, headers and libraries are packed into a single archive. Each > package should contain latest CRT, headers, GCC and GDB on the day it > was built. You just need to decompress it somewhere, add the `bin` > directory into your `PATH` and build using it. Thanks for the link. I am curious though why you could not have supplied alternative versions of the mingw-64/gcc threading library rather than entirely new builds of mingw-64/gcc ? Did you actually have to modify other modules of mingw-64/gcc to get your library to work with it ? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Using mcfgthread instead of the gcc thread library
On 4/9/2017 2:00 AM, Liu Hao wrote: > On 2017/4/9 8:12, Edward Diener wrote: >> 1) if mcfgthread replaces the mingw-64/gcc-6.3 threading library when used. > It takes the place of winpthreads completely. > >> 2) if it replaces the mingw-64/gcc-6.3 threading library even when I had >> installed mingw-64/gcc-6.3 with posix threading support as opposed to >> Windows threading support. > It is not possible. You have to rebuild GCC libraries, which in turn > requires rebuilding GCC itself. (You don't have to have Clang to build > libcxx, but sadly this isn't the case on GCC.) Are you saying that I have to build gcc-6.3 myself on Windows, rather than juat install it from mingw-w64-install, in order to use your library ? > > The file `libpthread.a` is not provided. That is to say, if you are > building GCC while you don't have winpthreads you have to put an empty > file in `@prefix@/lib`. This file can be safely deleted once you get > your GCC working. > > There is usually no other problem, unless you are linking against a 3rd > party library that has `libgcc` and `libstdc++` linked statically. > >> 3) if I replace the functionality in the mingw-64/gcc-6.3 threading >> library with mcfgthread by merely adding the mcfgthread DLL import >> library when compiling with mingw-64/gcc-6.3, and making sure the >> mcfgthread DLL library is in my Windows PATH. > Correct. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Using mcfgthread instead of the gcc thread library
I have been able to build mcfgthread from https://github.com/lhmouse/mcfgthread as an alternative to the gcc threading library for mingw-64/gcc-6.3. The reason I want to use mcfgthread is because the threading library for mingw-64/gcc-6.3 has a bug as documented at the currently open bug report https://sourceforge.net/p/mingw-w64/bugs/597/. The bug in this report manifests itself when I build the LLVM lld.exe linker using mingw-64/gcc-6.3. The bug causes lld.exe to hang when I am targeting VC++ and trying to link PE/COFF objects files, as opposed to targeting mingw-64/gcc and linking ELF object files where lld.exe works properly. But I am not sure: 1) if mcfgthread replaces the mingw-64/gcc-6.3 threading library when used. 2) if it replaces the mingw-64/gcc-6.3 threading library even when I had installed mingw-64/gcc-6.3 with posix threading support as opposed to Windows threading support. 3) if I replace the functionality in the mingw-64/gcc-6.3 threading library with mcfgthread by merely adding the mcfgthread DLL import library when compiling with mingw-64/gcc-6.3, and making sure the mcfgthread DLL library is in my Windows PATH. Any help with this issue would be greatly appreciated. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Moving sources from SourceForge to something better
Please, please consider moving mingw-64 sources from SourceForge to some better hosting server. SourceForge has morphed into a real disaster where downloading files from it are met by numerous tactics of delay and failure to force users to view their ads. Programming end-users should not have to be up with this nonsense and there are numerous better hosting servers for programming sources which do not waste programmer's time and patience. The latest attempts to download distributions with the mingw-64 install program are met with delays and failures because SourceForge can no longer respond to download requests in any reasonable time. Please give uo on an increasingly crippled and crippling SourceForge for something better. Thank you ! -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Problem with mingw-64 installer and gcc 5.3
The mingw-w64-install.exe installer produces an error when trying to install gcc-5.3. First the installer generates an incorrect default name for the final directory, using 'rev1' while listing the gcc-5.3 as being only revision 0 when choosing it. Then during the install a message box occurs with a big X in a red circle and the message "ERROR res", whatever that is supposed to mean. It also appears that the installer still thinks it is supposed to be installing 'rev1' erroneously, which is probably causing the error since it is probably looking to download a file which does not exist ( just guessing ). Whatever the problem which causes the "ERROR res" it needs to be corrected to get the installer to work installing gcc-5.3. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Latest mingw-w64-install broken on all Window versions
The latest mingw-w64-install program is broken on all Window versions ( Vista, 7, 8.1 ) in which I tried to use it. Attempting to install any of the releases listed always gives a ERROR Res message box and no files, except for ones at the top level, get installed. Uninstalling from Programs and Features works fine but no mingw-64 release can be installed with the program. I searched the Internet about this and found a number of hits going back to 2014 about this, implying it was fixed, but maybe the latest release has broken it again. Since the install is totally broken for now, where do I go to manually download and install the releases I want ? I looked under SourceForge Files for mingw-64 but could not find the releases there. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Latest mingw-w64-install broken on all Window versions
On 8/5/2015 12:21 PM, K. Frank wrote: Hello Edward! On Wed, Aug 5, 2015 at 10:35 AM, Edward Diener eldlistmaili...@tropicsoft.com wrote: The latest mingw-w64-install program is broken on all Window versions ( Vista, 7, 8.1 ) in which I tried to use it. I had a similar problem back in November in that the installer didn't work (on 64-bit windows 7). I don't remember the details. ... Since the install is totally broken for now, where do I go to manually download and install the releases I want ? I looked under SourceForge Files for mingw-64 but could not find the releases there. If you want posix threads and SEH exceptions, one possibility for the latest and greatest would be the compressed file: x86_64-5.1.0-release-posix-seh-rt_v4-rev0.7z downloadable from the sourceforge folder with url: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/5.1.0/threads-posix/seh/ I did the equivalent back in November for the 4.9.2 version. (Note, I haven't actually used the 5.1.0 version, but I assume that it works.) There are other possibilities (different builds, different configuration choices): see the sourceforge folder: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/ You could follow, for example, the mingw-builds link there and pick your desired configuration / version as you navigate down to the downloadable file. Happy 64-bit g++ Hacking! The problem is that the install program lists a release ( 4.9.3 ) that really does not exist yet. When I attempted to install that release the error message of my OP occurs. Installing releases that actually exist works. Evidently the install program has no logic to see that there is really nothing there for a particular release directory and so it lists a release that does not exist and then when it tries to retrieve the files it puts out an error message which means nothing to the end user. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'
On 7/31/2015 12:27 PM, Óscar Fuentes wrote: Edward Diener eldlistmaili...@tropicsoft.com writes: Calling a virtual member requires an access to the vtable of the class. The vtable is defined on the dll that contains the class' code. If the class is not exported, the vtable is not exported. The errors you are seeing is the linker complaining about the missing vtable. So you are saying that any class with virtual functions must have the class itself exported rather than the individual member functions when using gcc ? Because with VC++ that is not the case, so it must be an issue with gcc on Windows. Not sure what VC++ does, exactly, but this: https://msdn.microsoft.com/en-us/library/81h27t8c.aspx /quote If you export one virtual function in a class, you must export all of them, or at least provide versions that the client can use directly. If you have a class in which you are using selective member import/export with virtual functions, the functions must be in the exportable interface or defined inline (visible to the client). /end quote seems to say that you can't export some selected virtual members defined in .cpp files and hide the rest of the class. In my example all declared virtual functions are exported/imported. Please note that all versions of VC++, from 8 through the recent 14, have no problems compiling/linking the two shared libraries. VC++ does not require that implicit compiler-generated functions be exported/imported. It just works as is with what you declare and define. But of course mingw-64/gcc/ld does have these problems. Yet I keep hearing that this is somehow my fault rather than that of mingw-64/gcc/ld. No doubt I am supposed to figure out the voodoo which will cause mingw-64/gcc/ld to work. Even when I ask where to report this problem I am shaken off as if I have done something wrong rather than that the mingw-64/gcc/ld compile-link system is broken in some way when it refuses to link the second shared library. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'
On 7/31/2015 12:27 PM, Óscar Fuentes wrote: Edward Diener eldlistmaili...@tropicsoft.com writes: Calling a virtual member requires an access to the vtable of the class. The vtable is defined on the dll that contains the class' code. If the class is not exported, the vtable is not exported. The errors you are seeing is the linker complaining about the missing vtable. So you are saying that any class with virtual functions must have the class itself exported rather than the individual member functions when using gcc ? Because with VC++ that is not the case, so it must be an issue with gcc on Windows. Not sure what VC++ does, exactly, but this: https://msdn.microsoft.com/en-us/library/81h27t8c.aspx /quote If you export one virtual function in a class, you must export all of them, or at least provide versions that the client can use directly. If you have a class in which you are using selective member import/export with virtual functions, the functions must be in the exportable interface or defined inline (visible to the client). /end quote seems to say that you can't export some selected virtual members defined in .cpp files and hide the rest of the class. Evidently adding a virtual destructor to ex_xml_exception in my example solves the link problem in my example. Why that is necessary I have no idea. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'
On 7/31/2015 7:45 AM, Óscar Fuentes wrote: Edward Diener eldlistmaili...@tropicsoft.com writes: I'm not sure this is a GCC bug. Does the linker error also occur when using static libraries, and when you dllexport the whole class as opposed to the functions you're explicitly defining? I have tried neither. I believe this error is the same as your previous one: you're not dllexporting some implictly defined functions. Which ones ? You can see the code. The code is far from being a minimal example, so I didn't look at it all, but I see that the class ex_exception is not exported (EX_VISIBLE expands to ... __visibility__(default)... and you set -fvisibility=hidden in your compile command). If your class has virtual members (as it seems the case) this is asking for trouble. I am sorry but this is asking for trouble means absolutely nothing to me on a technical level. Now, if this is what MSVC does, perhaps GCC should be modified to follow that behaviour, but that is not certain at this point. It has to be a bug in either gcc or ld using mingw-64 unless you can show me what is wrong with the code which produces the link errors. Unless you tell me that gcc/ld on Windows is incapable of exporting/importing individual member functions of a class rather than the class as a whole this is a bug somewhere in gcc/ld. As you know C++ requires more info than the member address/signature to be able to call that method when it is virtual or there are some constructor/copier/etc involved. No, I don't know what you are saying. Please be explicit and tell me what is lacking in my code. I realize that you and Ruben are trying to help me figure out what I need to do in order not to get the link errors I have showed in my example, but unless you can be specific as to what has to change in the code, which looks perfectly fine AFAICS, vague comments are not going to solve this problem. I can assure you that I have enough C++ expertise to understand whatever specific things you want to tell me. If you tell me that exporting/importing individual functions of a class does not work with mingw-64/gcc/ld when virtual inheritance is involved, that's fine but I would like to see some sort of docs explaining this. In fact if there are docs explaining all the rules of exporting/importing individual functions of a class using mingw-64/gcc I will be glad to read them. The code example I have shown is a very simplified version of a much larger situation in the build of the Boost serialization library, but it shows the problem in building the library adequately. I am trying to help debug problems in building the wide character version of the library using gcc on Windows. I did not design and code any portion of the original library so I am trying to minimize any one-off changes that have to be made to build the wide character version of the library using mingw-64/gcc. Therefore I am very concerned at making the absolutely minimal number of changes necessary to get the code to build and work properly. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'
On 7/31/2015 8:52 AM, Óscar Fuentes wrote: Edward Diener eldlistmaili...@tropicsoft.com writes: The code is far from being a minimal example, so I didn't look at it all, but I see that the class ex_exception is not exported (EX_VISIBLE expands to ... __visibility__(default)... and you set -fvisibility=hidden in your compile command). If your class has virtual members (as it seems the case) this is asking for trouble. I am sorry but this is asking for trouble means absolutely nothing to me on a technical level. Calling a virtual member requires an access to the vtable of the class. The vtable is defined on the dll that contains the class' code. If the class is not exported, the vtable is not exported. The errors you are seeing is the linker complaining about the missing vtable. So you are saying that any class with virtual functions must have the class itself exported rather than the individual member functions when using gcc ? Because with VC++ that is not the case, so it must be an issue with gcc on Windows. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'
On 7/31/2015 9:40 AM, Ruben Van Boxem wrote: 2015-07-31 13:07 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com mailto:eldlistmaili...@tropicsoft.com: On 7/31/2015 6:05 AM, Ruben Van Boxem wrote: 2015-07-31 2:04 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com mailto:eldlistmaili...@tropicsoft.com mailto:eldlistmaili...@tropicsoft.com mailto:eldlistmaili...@tropicsoft.com: On 7/30/2015 10:48 AM, Óscar Fuentes wrote: Edward Diener eldlistmaili...@tropicsoft.com mailto:eldlistmaili...@tropicsoft.com mailto:eldlistmaili...@tropicsoft.com mailto:eldlistmaili...@tropicsoft.com writes: Another thing is to get some hints from a .map-file. Add -Wl,--print-map,--sort-common,--cref file.map at the of the link-cmd. I could not find any documentation regarding the linker options you specify in the gcc documentation. Are they mingw-64 specific ? If so where would thye be documented ? Those are not gcc options, but `ld' (the GNU linker) options. -Wl directs gcc to pass the following comma-separated options to ld. To whom do I report this bug ? Does it go to mingw-64, to gcc, to the ld linker on Windows ? I have shown this bug occurring through the example I posted and I do not think anything I have shown is not standard C++. It can be reproduced by anyone. I am not knowledgeable enough about the workings of mingw-64/gcc or mingw-64/ld to be able to figure out why this bug is occurring but someone knowledgeable enough should be able to fix what needs to be fixed. I'm not sure this is a GCC bug. Does the linker error also occur when using static libraries, and when you dllexport the whole class as opposed to the functions you're explicitly defining? I have tried neither. It would be a helpful experiment. The reason I did not try it is that the design of the library, which is not my own, I am trying to fix does not export the whole class, but only particular member functions. In my own design of Windows dlls I always export an entire class but I can not overrule the design of someone else's library. I believe this error is the same as your previous one: you're not dllexporting some implictly defined functions. Which ones ? You can see the code. As I said in my previous crystal ball solution to that problem, it would definitely help if c++filt worked again. Hmm, it just occurred to me that adding an underscore to the name would change how c++filt looks at a name. The linker cannot find functions it needs in ex_xml_exception::~ex_xml_exception() This function is empty, so there are implicit function definitions at play, which as I said, have no reason to be dllexported by default. Now, if this is what MSVC does, perhaps GCC should be modified to follow that behaviour, but that is not certain at this point. It has to be a bug in either gcc or ld using mingw-64 unless you can show me what is wrong with the code which produces the link errors. Unless you tell me that gcc/ld on Windows is incapable of exporting/importing individual member functions of a class rather than the class as a whole this is a bug somewhere in gcc/ld. The thing is, you're not exporting the implicitly defined functions. Because you haven't defined them with the dllexport attribute, nor is the class as a whole dllexported, do its functions can't inherit that attribute. Which are the implicitly defined functions I must export individually ? Note that with the ex_exception class accessed from outside the shared library there is no problem but with the ex_xml_exception class there is a problem. Why can you not dllexport the whole class, if I may ask? Note that e.g. this web page (http://www.codeproject.com/Articles/28969/HowTo-Export-C-classes-from-a-DLL) discusses the problems and workarounds. None of the options there says to export individual functions. Probably because it leads to exactly this type of issue. Also, I don't think the virtual inheritance has anything to do with it. Glad to hear that. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'
On 7/30/2015 2:48 AM, Gisle Vanem wrote: Edward Diener wrote: If I remove the declaration and definition of ex_xml_exception::what(), since it is not needed, when linking I get: throw_exception_ex.o:throw_exception_ex.cpp:(.rdata$_ZTV16ex_xml_exception[__ZTV16ex_xml_exception]+0x20): undefined reference to `virtual thunk to ex_exception::what() const' throw_exception_ex.o:throw_exception_ex.cpp:(.rdata$_ZTC16ex_xml_exception4_12ex_exception[__ZTC16ex_xml_exception4_12ex_exception]+0x38): undefined reference to `virtual thunk to ex_exception::what() const' collect2.exe: error: ld returned 1 exit status AFAICS, that is because you have virtualised the whole 'ex_exception' class in your 'ex_xml_exception' class. Why? What happens if you virtualise only those functions you need to specialize? Another thing is to get some hints from a .map-file. Add -Wl,--print-map,--sort-common,--cref file.map at the of the link-cmd. I could not find any documentation regarding the linker options you specify in the gcc documentation. Are they mingw-64 specific ? If so where would thye be documented ? -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'
On 7/30/2015 10:48 AM, Óscar Fuentes wrote: Edward Diener eldlistmaili...@tropicsoft.com writes: Another thing is to get some hints from a .map-file. Add -Wl,--print-map,--sort-common,--cref file.map at the of the link-cmd. I could not find any documentation regarding the linker options you specify in the gcc documentation. Are they mingw-64 specific ? If so where would thye be documented ? Those are not gcc options, but `ld' (the GNU linker) options. -Wl directs gcc to pass the following comma-separated options to ld. To whom do I report this bug ? Does it go to mingw-64, to gcc, to the ld linker on Windows ? I have shown this bug occurring through the example I posted and I do not think anything I have shown is not standard C++. It can be reproduced by anyone. I am not knowledgeable enough about the workings of mingw-64/gcc or mingw-64/ld to be able to figure out why this bug is occurring but someone knowledgeable enough should be able to fix what needs to be fixed. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'
On 7/30/2015 10:48 AM, Óscar Fuentes wrote: Edward Diener eldlistmaili...@tropicsoft.com writes: Another thing is to get some hints from a .map-file. Add -Wl,--print-map,--sort-common,--cref file.map at the of the link-cmd. I could not find any documentation regarding the linker options you specify in the gcc documentation. Are they mingw-64 specific ? If so where would thye be documented ? Those are not gcc options, but `ld' (the GNU linker) options. -Wl directs gcc to pass the following comma-separated options to ld. -- Thanks, I was able to pass the options to ld and get a map file for both shared libraries. Unfortunately even with the map files, which are pretty extensive, I cannot decipher why the link is failing. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'
On 7/30/2015 2:48 AM, Gisle Vanem wrote: Edward Diener wrote: If I remove the declaration and definition of ex_xml_exception::what(), since it is not needed, when linking I get: throw_exception_ex.o:throw_exception_ex.cpp:(.rdata$_ZTV16ex_xml_exception[__ZTV16ex_xml_exception]+0x20): undefined reference to `virtual thunk to ex_exception::what() const' throw_exception_ex.o:throw_exception_ex.cpp:(.rdata$_ZTC16ex_xml_exception4_12ex_exception[__ZTC16ex_xml_exception4_12ex_exception]+0x38): undefined reference to `virtual thunk to ex_exception::what() const' collect2.exe: error: ld returned 1 exit status AFAICS, that is because you have virtualised the whole 'ex_exception' class in your 'ex_xml_exception' class. It is perfectly valid C++ to do so. Why should I get a gcc linker error for valid C++ code ? Why? I am simply duplicating in a much simplified form code that exists elsewhere, trying to solve a far more complicated problem not of my own originally. What happens if you virtualise only those functions you need to specialize? I can try that. Please understand that the issue is not what may work but why valid C++ will not work. Another thing is to get some hints from a .map-file. Add -Wl,--print-map,--sort-common,--cref file.map at the of the link-cmd. I will try that to see if the .map file will tell me anything about the linker error I am getting. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'
On 7/28/2015 8:49 AM, Ruben Van Boxem wrote:
2015-07-28 14:44 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com
mailto:eldlistmaili...@tropicsoft.com:
On 7/28/2015 8:27 AM, Edward Diener wrote:
Without trying immediately to give specific code for what is a large
project, I am getting linker errors when trying to link a second
shared
library which depends on a first shared library that has linked
successfully. The errors are:
xml_wgrammar.o:xml_wgrammar.cpp:(.rdata$_ZTVN5boost7archive21xml_archive_exceptionE[__ZTVN5boost7archive21xml_archive_exceptionE]+0x20):
undefined reference to `virtual thunk to
boost::archive::archive_exception::what() const'
xml_wgrammar.o:xml_wgrammar.cpp:(.rdata$_ZTCN5boost7archive21xml_archive_exceptionE4_NS0_17archive_exceptionE[__ZTCN5boost7archive21xml_archive_exceptionE4_NS0_17archive_exceptionE]+0x38):
undefined reference to `virtual thunk to
boost::archive::archive_exception::what() const'
collect2.exe: error: ld returned 1 exit status
The xml_wgrammar.o file is being linked into the second shared
library.
The xml_wgrammar.cpp file includes xml_archive_exception.hpp. The
xml_archive_exception.hpp includes and derives from
archive_exception.hpp. Both xml_archive_exception and
archive_exception
have their implementation in the first shared library and have their
necessary implementations exported. The implementation of
archive_exception::what() is exported in the first shared library
and is
imported when seen by xml_wgrammar.cpp.
What is so strange is that there is no call to
archive_exception::what()
in the preprocessed output of xml_wgrammar.cpp.
Does anybody have any idea what might be going on here before I
take the
time to reduce this situation into a short enough fragment to
show in a
subsequent thread in this post ?
After adding an xml_archive_exception::what() implementation which just
calls its base class archive_exception::what() implementation I now
receive the linker errors:
xml_wgrammar.o: In function
`ZN5boost7archive21xml_archive_exceptionD1Ev':
xml_archive_exception.hpp:34: undefined reference to `vtable for
boost::archive::xml_archive_exception'
xml_archive_exception.hpp:34: undefined reference to `vtable for
boost::archive::xml_archive_exception'
xml_archive_exception.hpp:34: undefined reference to `vtable for
boost::archive::xml_archive_exception'
xml_archive_exception.hpp:34: undefined reference to `VTT for
boost::archive::xml_archive_exception'
collect2.exe: error: ld returned 1 exit status
Perhaps this will give someone an idea of what might be happening.
You're not linking to the boost_serialization library. At least on my
system (Linux) boost::archive::{xml_,}archive_exception::what() is
defined there.
Add -lboost_serialization to your linker command or do the same
through your build system.
Note that Boost has #pragma lib ... to tell MSVC to link the required
libraries. GCC does not have such a functionality.
Here are simplified files to reproduce the problem.
// ex_decl.hpp
#ifndef EX_DECL_HPP
#define EX_DECL_HPP
#if defined(BLD_EX_EXAMPLE)
#define EX_DECL __attribute__((__dllexport__))
#else
#define EX_DECL __attribute__((__dllimport__))
#endif
#define EX_VISIBLE __attribute__((__visibility__(default)))
#endif // EX_DECL_HPP
// ex_exception.hpp
#ifndef EX_EXCEPTION_HPP
#define EX_EXCEPTION_HPP
#include exception
#include ex_decl.hpp
class EX_VISIBLE ex_exception :
public virtual std::exception
{
private:
char m_buffer[128];
protected:
EX_DECL unsigned int
append(unsigned int l, const char * a);
EX_DECL
ex_exception() ;
public:
typedef enum {
no_exception, // initialized without code
other_exception// any excepton not listed below
} ex_exception_code;
ex_exception_code code;
EX_DECL ex_exception(
ex_exception_code c,
const char * e1 = 0,
const char * e2 = 0
) ;
EX_DECL ex_exception(ex_exception const ) ;
virtual EX_DECL ~ex_exception() throw() ;
virtual EX_DECL const char * what() const throw() ;
};
#endif // EX_EXCEPTION_HPP
// ex_exception.cpp
#include exception
#include cstring
#define BLD_EX_EXAMPLE
#include ex_exception.hpp
EX_DECL unsigned int ex_exception::append(unsigned int l, const char * a){
while(l (sizeof(m_buffer) - 1)){
char c = *a++;
if('\0' == c)
break;
m_buffer[l++] = c;
}
m_buffer[l] = '\0';
return l;
}
EX_DECL ex_exception::ex_exception(ex_exception_code c,const char *
e1,const char * e2) :
code(c)
{
unsigned int length = 0;
switch(code){
case no_exception
Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'
On 7/28/2015 8:49 AM, Ruben Van Boxem wrote:
2015-07-28 14:44 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com
mailto:eldlistmaili...@tropicsoft.com:
On 7/28/2015 8:27 AM, Edward Diener wrote:
Without trying immediately to give specific code for what is a large
project, I am getting linker errors when trying to link a second
shared
library which depends on a first shared library that has linked
successfully. The errors are:
xml_wgrammar.o:xml_wgrammar.cpp:(.rdata$_ZTVN5boost7archive21xml_archive_exceptionE[__ZTVN5boost7archive21xml_archive_exceptionE]+0x20):
undefined reference to `virtual thunk to
boost::archive::archive_exception::what() const'
xml_wgrammar.o:xml_wgrammar.cpp:(.rdata$_ZTCN5boost7archive21xml_archive_exceptionE4_NS0_17archive_exceptionE[__ZTCN5boost7archive21xml_archive_exceptionE4_NS0_17archive_exceptionE]+0x38):
undefined reference to `virtual thunk to
boost::archive::archive_exception::what() const'
collect2.exe: error: ld returned 1 exit status
The xml_wgrammar.o file is being linked into the second shared
library.
The xml_wgrammar.cpp file includes xml_archive_exception.hpp. The
xml_archive_exception.hpp includes and derives from
archive_exception.hpp. Both xml_archive_exception and
archive_exception
have their implementation in the first shared library and have their
necessary implementations exported. The implementation of
archive_exception::what() is exported in the first shared library
and is
imported when seen by xml_wgrammar.cpp.
What is so strange is that there is no call to
archive_exception::what()
in the preprocessed output of xml_wgrammar.cpp.
Does anybody have any idea what might be going on here before I
take the
time to reduce this situation into a short enough fragment to
show in a
subsequent thread in this post ?
After adding an xml_archive_exception::what() implementation which just
calls its base class archive_exception::what() implementation I now
receive the linker errors:
xml_wgrammar.o: In function
`ZN5boost7archive21xml_archive_exceptionD1Ev':
xml_archive_exception.hpp:34: undefined reference to `vtable for
boost::archive::xml_archive_exception'
xml_archive_exception.hpp:34: undefined reference to `vtable for
boost::archive::xml_archive_exception'
xml_archive_exception.hpp:34: undefined reference to `vtable for
boost::archive::xml_archive_exception'
xml_archive_exception.hpp:34: undefined reference to `VTT for
boost::archive::xml_archive_exception'
collect2.exe: error: ld returned 1 exit status
Perhaps this will give someone an idea of what might be happening.
You're not linking to the boost_serialization library. At least on my
system (Linux) boost::archive::{xml_,}archive_exception::what() is
defined there.
I am working to get the latest version of the Boost serialization
library from source on Github to build under mingw-64/gcc-5.1 on
Windows. I am now to the point where I can build the narrow character
version of the library but when attempting to link the wide character
version of the library, which depends on classes in the narrow character
version of the library, I am encountering the errors in this post, as
specified above. The linker line, from Boost build ( I have elided the
full paths ), is:
g++ -Wl,--out-implib,libboost_wserialization-mgw51-d-1_59.dll.a -o
libboost_wserialization-mgw51-d-1_59.dll -shared -Wl,--start-group
basic_text_wiprimitive.o basic_text_woprimitive.o text_wiarchive.o
text_woarchive.o utf8_codecvt_facet.o xml_wgrammar.o
xml_wiarchive.o xml_woarchive.o codecvt_null.o
libboost_serialization-mgw51-d-1_59.dll.a -Wl,-Bstatic -Wl,-Bdynamic
-Wl,--end-group -g -march=i686 -m32
You can see that the I am linking in the boost serialization library
when attempting to build the wide character version of the library.
Add -lboost_serialization to your linker command or do the same
through your build system.
Note that Boost has #pragma lib ... to tell MSVC to link the required
libraries. GCC does not have such a functionality.
Yes, I understand all that.
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'
On 7/28/2015 8:27 AM, Edward Diener wrote: Without trying immediately to give specific code for what is a large project, I am getting linker errors when trying to link a second shared library which depends on a first shared library that has linked successfully. The errors are: xml_wgrammar.o:xml_wgrammar.cpp:(.rdata$_ZTVN5boost7archive21xml_archive_exceptionE[__ZTVN5boost7archive21xml_archive_exceptionE]+0x20): undefined reference to `virtual thunk to boost::archive::archive_exception::what() const' xml_wgrammar.o:xml_wgrammar.cpp:(.rdata$_ZTCN5boost7archive21xml_archive_exceptionE4_NS0_17archive_exceptionE[__ZTCN5boost7archive21xml_archive_exceptionE4_NS0_17archive_exceptionE]+0x38): undefined reference to `virtual thunk to boost::archive::archive_exception::what() const' collect2.exe: error: ld returned 1 exit status The xml_wgrammar.o file is being linked into the second shared library. The xml_wgrammar.cpp file includes xml_archive_exception.hpp. The xml_archive_exception.hpp includes and derives from archive_exception.hpp. Both xml_archive_exception and archive_exception have their implementation in the first shared library and have their necessary implementations exported. The implementation of archive_exception::what() is exported in the first shared library and is imported when seen by xml_wgrammar.cpp. What is so strange is that there is no call to archive_exception::what() in the preprocessed output of xml_wgrammar.cpp. Does anybody have any idea what might be going on here before I take the time to reduce this situation into a short enough fragment to show in a subsequent thread in this post ? After adding an xml_archive_exception::what() implementation which just calls its base class archive_exception::what() implementation I now receive the linker errors: xml_wgrammar.o: In function `ZN5boost7archive21xml_archive_exceptionD1Ev': xml_archive_exception.hpp:34: undefined reference to `vtable for boost::archive::xml_archive_exception' xml_archive_exception.hpp:34: undefined reference to `vtable for boost::archive::xml_archive_exception' xml_archive_exception.hpp:34: undefined reference to `vtable for boost::archive::xml_archive_exception' xml_archive_exception.hpp:34: undefined reference to `VTT for boost::archive::xml_archive_exception' collect2.exe: error: ld returned 1 exit status Perhaps this will give someone an idea of what might be happening. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'
Without trying immediately to give specific code for what is a large project, I am getting linker errors when trying to link a second shared library which depends on a first shared library that has linked successfully. The errors are: xml_wgrammar.o:xml_wgrammar.cpp:(.rdata$_ZTVN5boost7archive21xml_archive_exceptionE[__ZTVN5boost7archive21xml_archive_exceptionE]+0x20): undefined reference to `virtual thunk to boost::archive::archive_exception::what() const' xml_wgrammar.o:xml_wgrammar.cpp:(.rdata$_ZTCN5boost7archive21xml_archive_exceptionE4_NS0_17archive_exceptionE[__ZTCN5boost7archive21xml_archive_exceptionE4_NS0_17archive_exceptionE]+0x38): undefined reference to `virtual thunk to boost::archive::archive_exception::what() const' collect2.exe: error: ld returned 1 exit status The xml_wgrammar.o file is being linked into the second shared library. The xml_wgrammar.cpp file includes xml_archive_exception.hpp. The xml_archive_exception.hpp includes and derives from archive_exception.hpp. Both xml_archive_exception and archive_exception have their implementation in the first shared library and have their necessary implementations exported. The implementation of archive_exception::what() is exported in the first shared library and is imported when seen by xml_wgrammar.cpp. What is so strange is that there is no call to archive_exception::what() in the preprocessed output of xml_wgrammar.cpp. Does anybody have any idea what might be going on here before I take the time to reduce this situation into a short enough fragment to show in a subsequent thread in this post ? -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Linker problem with i686-5.1.0-posix-dwarf-rt_v4-rev0 version
On 7/27/2015 5:00 AM, Ruben Van Boxem wrote:
2015-07-27 8:54 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com
mailto:eldlistmaili...@tropicsoft.com:
On 7/24/2015 11:13 AM, Ruben Van Boxem wrote:
2015-07-24 17:03 GMT+02:00 Edward Diener
eldlistmaili...@tropicsoft.com
mailto:eldlistmaili...@tropicsoft.com
mailto:eldlistmaili...@tropicsoft.com
mailto:eldlistmaili...@tropicsoft.com:
On 7/24/2015 8:54 AM, Riot wrote:
Where are you defining your template, in the header or the
source? You
may need to explicitly instantiate.
The template is being defined in the YY.cpp source file.
Could you send example files displaying the issue? It makes it easier to
reproduce and debug the issue.
Here are the files and the command lines. All files should be placed in
the same source directory with a 'debug' sub-directory where everything
will be built. You need to have the mingw-64 gcc-5.1 32-bit bin
directory in your PATH and you need to be in the source directory when
executing the commands. I am only concerned with problems linking and
not with running the result.
First the header and source file to be built into a shared library:
Header file exception_cl.hpp
#ifndef EXCEPTION_CL_HPP
#define EXCEPTION_CL_HPP
#include exception
#if defined(BUILD_SL)
#define CLASS_DECL __attribute__((__dllexport__))
#else
#define CLASS_DECL __attribute__((__dllimport__))
#endif
class __attribute__((__visibility__(default))) exception_cl :
public virtual std::exception
{
private:
char m_buffer[128];
public:
int code;
CLASS_DECL exception_cl(int) ;
virtual CLASS_DECL ~exception_cl() throw() ;
virtual CLASS_DECL const char * what() const throw() ;
};
#endif // EXCEPTION_CL_HPP
Source file exception_cl.cpp
#define BUILD_SL
#include exception_cl.hpp
CLASS_DECL
exception_cl::exception_cl(int i) :
code(i)
{
m_buffer[0] = '\0';
}
CLASS_DECL
exception_cl::~exception_cl() throw() {}
CLASS_DECL const char *
exception_cl::what( ) const throw() {
return m_buffer;
}
The command for compiling the source file is:
g++ -ftemplate-depth-128 -Wno-unused-local-typedefs
-ftrack-macro-expansion=0 -O0 -fno-inline -Wall -g -march=i686 -m32
-fvisibility-inlines-hidden -fvisibility=hidden -c -o
.\debug\exception_cl.o exception_cl.cpp
The command for linking the object file to a shared library called
lib-excl-mgw51 is:
g++ -Wl,--out-implib,.\debug\lib-excl-mgw51.dll.a -o
.\debug\lib-excl-mgw51.dll -shared -Wl,--start-group
.\debug\exception_cl.o -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group
-g -march=i686 -m32
These commands succeed without problems in creating the shared library
and the import library in the 'debug' subdirectory.
Now the source file to be built into an executable, which uses the
exception_cl class from the shared library. I call the source file
'throw_exception_cl.cpp':
#include exception_cl.hpp
templateclass E void throw_exception(E const e) { throw e; }
int main(int argc,char * argv[])
{
if (argc 1)
{
#if 1
throw_exception(exception_cl(0));
#else
throw exception_cl(0);
#endif
}
return 0;
}
The command for compiling the file is:
g++ -ftemplate-depth-128 -Wno-unused-local-typedefs
-ftrack-macro-expansion=0 -O0 -fno-inline -Wall -g -march=i686 -m32 -c
-o .\debug\throw_exception_cl.o throw_exception_cl.cpp
This command succeeds in creating the object file in the 'debug'
subdirectory.
Now the command to link the source file's object file into an
executable:
g++ -Wl,-R -Wl,.\debug -Wl,-rpath-link -Wl,.\debug -o
.\debug\te.exe -Wl,--start-group .\debug\throw_exception_cl.o
.\debug\lib-excl-mgw51.dll.a -Wl,-Bstatic -Wl,-Bdynamic
-Wl,--end-group -g -march=i686 -m32
This command fails with the messages:
.\debug\throw_exception_cl.o: In function `ZN12exception_clC1ERKS_':
C:\Programming\VersionControl\modular-boost\libs\serialization\src/exception_cl.hpp:12:
undefined reference to `vtable for exception_cl'
C:\Programming\VersionControl\modular-boost\libs\serialization\src/exception_cl.hpp:12:
undefined reference to `vtable for exception_cl'
collect2.exe: error: ld returned 1 exit status
If in the source file immediately above, the #if 1 line is changed to
if 0, the link command succeeds without error. But I need it to
succeed as is.
Please realize that this is all a much boiled
Re: [Mingw-w64-public] Linker problem with i686-5.1.0-posix-dwarf-rt_v4-rev0 version
On 7/24/2015 11:13 AM, Ruben Van Boxem wrote:
2015-07-24 17:03 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com
mailto:eldlistmaili...@tropicsoft.com:
On 7/24/2015 8:54 AM, Riot wrote:
Where are you defining your template, in the header or the source? You
may need to explicitly instantiate.
The template is being defined in the YY.cpp source file.
Could you send example files displaying the issue? It makes it easier to
reproduce and debug the issue.
Here are the files and the command lines. All files should be placed in
the same source directory with a 'debug' sub-directory where everything
will be built. You need to have the mingw-64 gcc-5.1 32-bit bin
directory in your PATH and you need to be in the source directory when
executing the commands. I am only concerned with problems linking and
not with running the result.
First the header and source file to be built into a shared library:
Header file exception_cl.hpp
#ifndef EXCEPTION_CL_HPP
#define EXCEPTION_CL_HPP
#include exception
#if defined(BUILD_SL)
#define CLASS_DECL __attribute__((__dllexport__))
#else
#define CLASS_DECL __attribute__((__dllimport__))
#endif
class __attribute__((__visibility__(default))) exception_cl :
public virtual std::exception
{
private:
char m_buffer[128];
public:
int code;
CLASS_DECL exception_cl(int) ;
virtual CLASS_DECL ~exception_cl() throw() ;
virtual CLASS_DECL const char * what() const throw() ;
};
#endif // EXCEPTION_CL_HPP
Source file exception_cl.cpp
#define BUILD_SL
#include exception_cl.hpp
CLASS_DECL
exception_cl::exception_cl(int i) :
code(i)
{
m_buffer[0] = '\0';
}
CLASS_DECL
exception_cl::~exception_cl() throw() {}
CLASS_DECL const char *
exception_cl::what( ) const throw() {
return m_buffer;
}
The command for compiling the source file is:
g++ -ftemplate-depth-128 -Wno-unused-local-typedefs
-ftrack-macro-expansion=0 -O0 -fno-inline -Wall -g -march=i686 -m32
-fvisibility-inlines-hidden -fvisibility=hidden -c -o
.\debug\exception_cl.o exception_cl.cpp
The command for linking the object file to a shared library called
lib-excl-mgw51 is:
g++ -Wl,--out-implib,.\debug\lib-excl-mgw51.dll.a -o
.\debug\lib-excl-mgw51.dll -shared -Wl,--start-group
.\debug\exception_cl.o -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group
-g -march=i686 -m32
These commands succeed without problems in creating the shared library
and the import library in the 'debug' subdirectory.
Now the source file to be built into an executable, which uses the
exception_cl class from the shared library. I call the source file
'throw_exception_cl.cpp':
#include exception_cl.hpp
templateclass E void throw_exception(E const e) { throw e; }
int main(int argc,char * argv[])
{
if (argc 1)
{
#if 1
throw_exception(exception_cl(0));
#else
throw exception_cl(0);
#endif
}
return 0;
}
The command for compiling the file is:
g++ -ftemplate-depth-128 -Wno-unused-local-typedefs
-ftrack-macro-expansion=0 -O0 -fno-inline -Wall -g -march=i686 -m32 -c
-o .\debug\throw_exception_cl.o throw_exception_cl.cpp
This command succeeds in creating the object file in the 'debug'
subdirectory.
Now the command to link the source file's object file into an executable:
g++ -Wl,-R -Wl,.\debug -Wl,-rpath-link -Wl,.\debug -o
.\debug\te.exe -Wl,--start-group .\debug\throw_exception_cl.o
.\debug\lib-excl-mgw51.dll.a -Wl,-Bstatic -Wl,-Bdynamic
-Wl,--end-group -g -march=i686 -m32
This command fails with the messages:
.\debug\throw_exception_cl.o: In function `ZN12exception_clC1ERKS_':
C:\Programming\VersionControl\modular-boost\libs\serialization\src/exception_cl.hpp:12:
undefined reference to `vtable for exception_cl'
C:\Programming\VersionControl\modular-boost\libs\serialization\src/exception_cl.hpp:12:
undefined reference to `vtable for exception_cl'
collect2.exe: error: ld returned 1 exit status
If in the source file immediately above, the #if 1 line is changed to
if 0, the link command succeeds without error. But I need it to
succeed as is.
Please realize that this is all a much boiled down example of the actual
problem that is occurring with mingw-64 gcc-5.1 32-bit compile, but it
shows the problem itself that is occurring in the actual code. The
problem also occurs in the other latest mingw-64 gcc-4.9.2 and 4.8.5 32
bit releases.
Any help or suggestions for solving this problem are much appreciated.
Thanks,
Ruben
On 24 Jul 2015 13:31, Edward Diener
eldlistmaili...@tropicsoft.com
mailto:eldlistmaili...@tropicsoft.com
mailto:eldlistmaili...@tropicsoft.com
mailto:eldlistmaili...@tropicsoft.com wrote:
Before attempting to reduce my code to a small enough example
to post
here in its entirety I will give a description of the problem
to see if
anyone has encountered
Re: [Mingw-w64-public] Linker problem with i686-5.1.0-posix-dwarf-rt_v4-rev0 version
On 7/24/2015 8:54 AM, Riot wrote:
Where are you defining your template, in the header or the source? You
may need to explicitly instantiate.
The template is being defined in the YY.cpp source file.
On 24 Jul 2015 13:31, Edward Diener eldlistmaili...@tropicsoft.com
mailto:eldlistmaili...@tropicsoft.com wrote:
Before attempting to reduce my code to a small enough example to post
here in its entirety I will give a description of the problem to see if
anyone has encountered it in general. The problem is purely a linker
problem.
I have an exported class in a shared library, called it XX in header
file XX.hpp. From an executable's source file, called it YY.cpp I
include the class's header file where the class will show as imported
and in the code in the source file I throw an exception with an instance
of the class, as in:
throw XX(some_constructor_parameters);
This compiles and links without error.
If instead I use a template to throw an exception, such as:
templateclass E void throw_exception(E const e) { throw e; }
and then invoke it from my executable as:
throw_exception(XX(some_constructor_parameters));
I receive a linker error of the form:
YY.o: In function `SomeDecoratedName':
XX.hpp:27: undefined reference to `vtable for XX'
XX.hpp:27: undefined reference to `vtable for XX'
I realize that this is not a complete example but before reducing my
code to the least possible example which will reproduce this problem I
thought I would ask if anyone has encountered anything like it, or has
any idea why using a template causes a linker error whereas not using
the template links would link without any problems.
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Linker problem with i686-5.1.0-posix-dwarf-rt_v4-rev0 version
On 7/24/2015 11:28 AM, Riot wrote:
If you're defining your template in the cpp file, you'll need to
explicitly instantiate it somewhere with the types you're using for it.
Alternatively, define it in the header and it'll be instantiated
wherever it's used with whatever types it's used with.
It makes not the slightest difference whether the definition is in the
XX.hpp header file or the YY.cpp source file. The same problem occurs.
Why should I have to explicitly instantiate the template for whatever
type(s) I am using ? I am not exporting the instantiation from the
shared library I create.
On 24 July 2015 at 16:03, Edward Diener eldlistmaili...@tropicsoft.com
mailto:eldlistmaili...@tropicsoft.com wrote:
On 7/24/2015 8:54 AM, Riot wrote:
Where are you defining your template, in the header or the source? You
may need to explicitly instantiate.
The template is being defined in the YY.cpp source file.
On 24 Jul 2015 13:31, Edward Diener
eldlistmaili...@tropicsoft.com
mailto:eldlistmaili...@tropicsoft.com
mailto:eldlistmaili...@tropicsoft.com
mailto:eldlistmaili...@tropicsoft.com wrote:
Before attempting to reduce my code to a small enough example
to post
here in its entirety I will give a description of the problem
to see if
anyone has encountered it in general. The problem is purely a
linker
problem.
I have an exported class in a shared library, called it XX in
header
file XX.hpp. From an executable's source file, called it YY.cpp I
include the class's header file where the class will show as
imported
and in the code in the source file I throw an exception with
an instance
of the class, as in:
throw XX(some_constructor_parameters);
This compiles and links without error.
If instead I use a template to throw an exception, such as:
templateclass E void throw_exception(E const e) {
throw e; }
and then invoke it from my executable as:
throw_exception(XX(some_constructor_parameters));
I receive a linker error of the form:
YY.o: In function `SomeDecoratedName':
XX.hpp:27: undefined reference to `vtable for XX'
XX.hpp:27: undefined reference to `vtable for XX'
I realize that this is not a complete example but before
reducing my
code to the least possible example which will reproduce this
problem I
thought I would ask if anyone has encountered anything like
it, or has
any idea why using a template causes a linker error whereas
not using
the template links would link without any problems.
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
mailto:Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Linker problem with i686-5.1.0-posix-dwarf-rt_v4-rev0 version
Before attempting to reduce my code to a small enough example to post
here in its entirety I will give a description of the problem to see if
anyone has encountered it in general. The problem is purely a linker
problem.
I have an exported class in a shared library, called it XX in header
file XX.hpp. From an executable's source file, called it YY.cpp I
include the class's header file where the class will show as imported
and in the code in the source file I throw an exception with an instance
of the class, as in:
throw XX(some_constructor_parameters);
This compiles and links without error.
If instead I use a template to throw an exception, such as:
templateclass E void throw_exception(E const e) { throw e; }
and then invoke it from my executable as:
throw_exception(XX(some_constructor_parameters));
I receive a linker error of the form:
YY.o: In function `SomeDecoratedName':
XX.hpp:27: undefined reference to `vtable for XX'
XX.hpp:27: undefined reference to `vtable for XX'
I realize that this is not a complete example but before reducing my
code to the least possible example which will reproduce this problem I
thought I would ask if anyone has encountered anything like it, or has
any idea why using a template causes a linker error whereas not using
the template links would link without any problems.
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Problem with intrinsics header files in gcc 5.1 implementation
On 7/4/2015 7:42 AM, Edward Diener wrote: In the intrin.h header there is an include of x86intrin.h whenever __GNUC__ is defined and we are compiling for x86 or x64. If you look at the x86intrin.h header file you will see it includes header files for all intrinsics. This leads to multiple typedefs using the same name for __m64, __m128, __m128d, and __m128i since these are declared later in the intrin.h header file as long as the particular CPU feature does not exist. Is this a known bug with the gcc 5.1 implementation of mingw-64 ? Please ignore as this is my user error. -- 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-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Problem with intrinsics header files in gcc 4.9 and up : redux
In the intrin.h header there is an include of x86intrin.h whenever __GNUC__ is defined and we are compiling for x86 or x64. If you look at the x86intrin.h header file you will see it includes header files for all intrinsics regardless of whether the CPU feature exists or not. This is true for gcc-4.9 on up. Yet for gcc below 4.9 the x86intrin.h only included an intrinsic header file if that CPU feature actually existed. I realize that this change of the x86intrin.h header from gcc-4.8 to gcc-4.9 and up may have been mandated by a change in gcc itself and not something done by the mingw-64 developers. In gcc 4.9 and up this leads to multiple typedefs using the same name for __m64, __m128, __m128d, and __m128i whenever the __MMX__ CPU feature does not exist and __MINGW_FORCE_SYS_INTRINS is not defined. Normally this is not a problem since __MINGW_FORCE_SYS_INTRINS is defined whenever the gcc version is 4.9 and up, and after all the header file change is precisely for gcc-4.9 and up implementations. But what happens if the intrin.h header file for gcc-4.9 and up is being used by a compiler implementation in which the gcc version is set below 4.9. Now __MINGW_FORCE_SYS_INTRINS is not defined and we do have multiple typedefs using the same __m64, __m128, __m128d, and __m128i names, which is of course a C++ error. Unfortunately such a compiler implementation does exist, namely 'clang' which uses the gcc headers and RTL. A recent update to the clang source now allows it to work with mingw-64 on Windows and automatically pick up whatever mingw-64 implementation is on the PATH. But clang still sets a value to its gcc version below that of 4.9. The workaround for this is obviously to define __MINGW_FORCE_SYS_INTRINS for such a compiler implementation, which now avoids the multiple same name typedef problem. I can attest that the workaround does work when using clang. But wouldn't it be better if the workaround were unnecessary. I think this can be done in the intrin.h header file by merely using the check which allowed the x86intrin.h to be originally included in the first place. So instead of: #ifndef __MINGW_FORCE_SYS_INTRINS #ifndef __MMX__ etc. as the first check for the MMX substitution typedefs in intrin.h it could be: #if !defined(__MINGW_FORCE_SYS_INTRINS) !(defined(__GNUC__) (defined(__i386__) || defined(__x86_64__))) #ifndef __MMX__ etc. I have tested this change out and it works fine with the mingw-64 gcc-5.1 implementation. -- 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-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Problem with intrinsics header files in gcc 5.1 implementation
In the intrin.h header there is an include of x86intrin.h whenever __GNUC__ is defined and we are compiling for x86 or x64. If you look at the x86intrin.h header file you will see it includes header files for all intrinsics. This leads to multiple typedefs using the same name for __m64, __m128, __m128d, and __m128i since these are declared later in the intrin.h header file as long as the particular CPU feature does not exist. Is this a known bug with the gcc 5.1 implementation of mingw-64 ? -- 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-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include and lib search paths for mingw-64
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 mingw-w64-492.bat @PATH=path-to-the-bin-directory;%PATH% @%* Now invoke that .bat with mingw-w64-492.bat g++ foo.cpp -o foo.exe mingw-w64-492.bat foo.exe Sure, but the point is that this should never be needed. The easiest solution is that any dll that cc1plus.exe needs should have been installed in the same directory as cc1plus.exe. Your other solution of putting the needed dlls in %WINDIR%/System32 is not very good unless all versions of such dlls are backward compatible since each new installation of mingw-64 might have its own version of a dll. 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, such as gcc, is invoked directly from the command line. 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 a regular basis. You are much better than the original mingw installations but your reliance on having to set the PATH rather than have a direct invocation work correctly is a real PITA. From what I recall, Visual Studio is even worse on this regard, as it requires setting some environment variables with paths to work. That's what vcvars32.bat does. How do you deal with multiple VS installs from the command line? Or you just use the IDE? I'm succesfully using the .bat method described above for multiple installs of VS and Mingw-w64. As my beloved mother used to say when I was a kid, Just because your friend Johnny wants to jump off the top of the Empire State building does that mean you have to do it too? -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include and lib search paths for mingw-64
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 libwinpthread, libstdc++ and co. on a directory that already is on PATH. But that would preclude having more than one MinGW(-w64) installed on your system, among other problems. You mention this as if it were some law of programming. Once again just because the relationships of modules ( exes and dlls ) are setup poorly in mingw-64 distros does not mean that this is the only way things could be. I have already explained that if you have all modules which need to reference each other in the same directory then some module finding another module will happen automatically in Windows. This would allow for self-enclosing distributions of mingw-64 which does NOT need the ridiculous nonsense of putting some bin directory in the PATH. You could distribute as many distros as you like and if they were all self-enclosing in the way I have mentioned you don't ever need the PATH environment variable set to any one distro's bin directory at any time. 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 versions and configurations, but there is no excuse for not understanding the point about the generated executables depending on the same (and more) dlls that cc1plus.exe depends on. Unless you pretend to emit your executables to the same bin directory where those dlls are, the cleanest solution is to add the bin directory to PATH. Yes, they could install cc1plus.exe on the same bin directory where g++.exe is. That would make you happy (at the cost of making others miserable) until the moment you realize that you need to set PATH anyways. Please explain to me why I would need to set PATH anyways to a particular toolchains bin directory if the dlls needed by any particular executable in a toolchain were in the same directory as the executable itself. Claiming otherwise to me, who am a programmer with a pretty good understanding of how modules work under Windows, is futile unless you want to ram down my throat the information that this is the way mingw-64 does things and we are not going to change. If so I already got that message. But claiming that you can't technically do it better, just because the idiots at Microsoft are the example which you choose to follow, is utter nonsense and I am pretty sure that if you are a programmer yourself you must know that. The model that MinGW(-w64) follows does not depend on what MS does or doesn't. But the fact that both toolsets have similar requirements wrt setting environment variables (with MinGW being the simplest, BTW) does tell us something about the space solution for the general problem. -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include and lib search paths for mingw-64
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 versions and configurations, but there is no excuse for not understanding the point about the generated executables depending on the same (and more) dlls that cc1plus.exe depends on. Unless you pretend to emit your executables to the same bin directory where those dlls are, the cleanest solution is to add the bin directory to PATH. Yes, they could install cc1plus.exe on the same bin directory where g++.exe is. That would make you happy (at the cost of making others miserable) until the moment you realize that you need to set PATH anyways. Please explain to me why I would need to set PATH anyways to a particular toolchains bin directory if the dlls needed by any particular executable in a toolchain were in the same directory as the executable itself. Ok, I'll try with different wording: Do you plan to create your executables in the bin directory of the toolchain? Surely not. As those executables compiled by you will depend on the same dlls that cc1plus.exe et al. depend on, you need to add the directory that holds those dlls to PATH (or copy them to the directory that holds your executable.) You have made a good point, but see my subsequent answers... My usage of mingw-64 might be to only compile, or to compile/link, without the need to run anything immediately. 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. One of the most favored methods of doing what you suggested is to copy whatever dlls are needed by the module created into the same directory where the module was created. This is no different from my suggestion that the same thing be done with a mingw-64 toolchain. But however I decided to do things it should be up to me to make that decision and not up to mingw-64 to create their own toolchain so that I am forced to add some toolchain's bin directory to my PATH just to compile and/or link my module. Furthermore with multiple toolchains your method of adding the toolchains bin directory to the PATH is asking for problems. What happens after I finish my compile/link cycle and test my program from within some batch file created simply for that purpose by temporarily putting some mingw-64's toolchain's bin directory in my PATH. I now go to run my program and the temporary addition to my PATH is gone and my program refuses to start. Now I have to go back and work out which mingw-64 toolchain created the program and which dlls I need from that toolchain. Clearly I am not going to add multiple toolchain bin directories to my PATH permanently, since any given module will now be picking up its dlls from the first toolchain bin directory in my PATH, which may not be the dlls that I need. In fact the whole business of adding any compiler toolchain's bin directory to the PATH permanently is a recipe for disaster. And if you think that the correct way to actually permanently execute my program is to do so from a batch file so that the correct toolchain's bin directory is in the PATH you are in a programming world which I am all too glad never to want to enter. I am not saying there is no place in programming where installing the latest same-named, totally backward compatible dll into a directory permananently in the PATH has its value. But that place is not multiple mingw-64 toolchains with their proliferation of dlls for compile and/or run-time use. I do understand why you say that the toolchain's bin directly may need to be added to the PATH in order to run my program directly after the compile/link cycle. But I would still heavily prefer that mingw-64 create their toolchains so that I can compile/link my program without having to manipulate the PATH variable in any way. Once I finish compile/link of my module(s) how I choose to ensure that the needed modules are in the correct place to run my program should be up to me. -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include and lib search paths for mingw-64
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 installs on their machines, that they use on a regular basis. You are much better than the original mingw installations but your reliance on having to set the PATH rather than have a direct invocation work correctly is a real PITA. 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 libwinpthread, libstdc++ and co. on a directory that already is on PATH. But that would preclude having more than one MinGW(-w64) installed on your system, among other problems. You mention this as if it were some law of programming. Once again just because the relationships of modules ( exes and dlls ) are setup poorly in mingw-64 distros does not mean that this is the only way things could be. I have already explained that if you have all modules which need to reference each other in the same directory then some module finding another module will happen automatically in Windows. This would allow for self-enclosing distributions of mingw-64 which does NOT need the ridiculous nonsense of putting some bin directory in the PATH. You could distribute as many distros as you like and if they were all self-enclosing in the way I have mentioned you don't ever need the PATH environment variable set to any one distro's bin directory at any time. Claiming otherwise to me, who am a programmer with a pretty good understanding of how modules work under Windows, is futile unless you want to ram down my throat the information that this is the way mingw-64 does things and we are not going to change. If so I already got that message. But claiming that you can't technically do it better, just because the idiots at Microsoft are the example which you choose to follow, is utter nonsense and I am pretty sure that if you are a programmer yourself you must know that. From what I recall, Visual Studio is even worse on this regard, as it requires setting some environment variables with paths to work. That's what vcvars32.bat does. How do you deal with multiple VS installs from the command line? Or you just use the IDE? I'm succesfully using the .bat method described above for multiple installs of VS and Mingw-w64. As my beloved mother used to say when I was a kid, Just because your friend Johnny wants to jump off the top of the Empire State building does that mean you have to do it too? That's not an answer to my question: how do you deal with multiple installs of VS? (I'm sure you have several of them, unless you use multiple machines, one for each) To recap: what you are experiencing is not a consequence of oversight or lazyness from the MinGW(-w64) developers, but the less annoying solution for the problem of installing one or more MinGW(-w64) instances without causing havoc. -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include and lib search paths for mingw-64
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 experience in the past with other GCC toolchains was that they tended to have enough usable relative search paths that you could still move them around wherever you want, as long as you didn't put *anything* at the hardcoded locations (/mingw or the like). That said, I haven't tried this with a MinGW-w64-based toolchain other than my own in a while. This is correct. Windows versions of gcc are fully relocatable (and were for years), the only problem you'll encounter with unpatched (or poorly-configured) gcc build is that anything in current drive\mingw\(include|lib) (or whatever the hardcoded path ends up pointing at) will be used by gcc (which is usually not what you want). It is not correct in my testing. If I don't have a c:\mingw but try to compile/link uisng a mingw-64/mingw32 installation directly I get an error message saying that a dll ( libwinpthread-1.dll ) can not be found even though it is in the same directory as the compiler and linker. With a c:\mingw directory I do not get this error. Back when i still used mingw.org, they had /mingw path hardcoded and would therefore suck up anything in currentdrive\mingw\(include|lib). This is/was a widely-known bug. Many builds (especially of Mingw-w64) hardcode (again, hardcoding is not intentional, it's a side effect of the build process that no one bothers to try to eliminate) an absolute DOS path to a directory that is unlikely to exist, thus sidestepping the issue this way. My solution, which eliminates the problem completely (AFAICS) was outlined earlier. Other builds may have something similar going as well. What you see as an archaic engineering feat that should be fixed as a bug is actually a quirk of a very complex non-Windows-oriented buildsystem of a piece of software that is very strict on what changes are accepted (especially to the buildsystem), who are they accepted from (you need to do a copyright assignment to contribute to gcc) and how they are vetted. This is just not worth bothering with for anyone who knows what the problem is. Fixing it on a per-build basis is easy enough. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include and lib search paths for mingw-64
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 releases as well as the predecessor mingw releases so I will try to be as civilized in my response as I can. So here goes: 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. All the initial exes and dlls are in this directory. The Windows search order for DLLs tells me that the DLL should be found automatically if it is in the same directory as whatever module loads it. The whole point of a self-enclosed distribution is that one should not have to do any tricks, such as setting a PATH variable, for the distribution to just work. If I have multiple mingw-64 distributions having to add the bin directory of each one to the PATH before I use that distribution is just as bad as having to have a c:\mingw directory link pointing to the one I execute. The correct design of mingw-64 ( or mingw ) would have me only execute the correct gcc and/or ld in the directory of the distribution to compile/link a program, without having to do anything further. 2015-06-21 18:28 GMT+03:00 Edward Diener eldlistmaili...@tropicsoft.com mailto:eldlistmaili...@tropicsoft.com: 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 absolute path of the build original location but if not there it's ignored as nonexistent directory. It owuld be nice if this won't happen but not critical. I am not seeing what you have described. If I completely remove c:\mingw I still get errors because libwinpthread-1.dll cannot be found even though it is clearly part of the mingw-64 gcc 5.1.0 distribution I am using to compile/link a program. Once I create a symbolic directory link from c:\mingw to the place where my 5.1. mingw32 directory has been installed everything works without problems. 2015-06-21 5:44 GMT+03:00 John E. / TDM tdra...@tdragon.net mailto:tdra...@tdragon.net mailto:tdra...@tdragon.net mailto:tdra...@tdragon.net: 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 now has gcc-5.1, but it has the same hardcoded to c:\mingw limitation which my OP is about. There may or may not be a TDM-GCC 5.1 release (5.1 being the first in the GCC 5 series); right now I try to track the second minor release in every major series, so expect TDM-GCC 5.2 at some point in the next month or two after the upstream 5.2 release. My experience in the past with other GCC toolchains was that they tended to have enough usable relative search paths that you could still move them around wherever you want, as long as you didn't put *anything* at the hardcoded locations (/mingw or the like). That said, I haven't tried this with a MinGW-w64-based toolchain other than my own in a while. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include and lib search paths for 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 absolute path of the build original location but if not there it's ignored as nonexistent directory. It owuld be nice if this won't happen but not critical. I am not seeing what you have described. If I completely remove c:\mingw I still get errors because libwinpthread-1.dll cannot be found even though it is clearly part of the mingw-64 gcc 5.1.0 distribution I am using to compile/link a program. Once I create a symbolic directory link from c:\mingw to the place where my 5.1. mingw32 directory has been installed everything works without problems. 2015-06-21 5:44 GMT+03:00 John E. / TDM tdra...@tdragon.net mailto:tdra...@tdragon.net: 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 now has gcc-5.1, but it has the same hardcoded to c:\mingw limitation which my OP is about. There may or may not be a TDM-GCC 5.1 release (5.1 being the first in the GCC 5 series); right now I try to track the second minor release in every major series, so expect TDM-GCC 5.2 at some point in the next month or two after the upstream 5.2 release. My experience in the past with other GCC toolchains was that they tended to have enough usable relative search paths that you could still move them around wherever you want, as long as you didn't put *anything* at the hardcoded locations (/mingw or the like). That said, I haven't tried this with a MinGW-w64-based toolchain other than my own in a while. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Include and lib search paths for mingw-64
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 different versions of mingw-64. Using relative paths to the installation would make running different versions of mingw-64 a breeze. I can understand why a build of clang on Windows targeting gcc would use absolute paths; clang uses the gcc headers and libraries so it needs some absolute path to find those gcc files. But why mingw-64 does this is beyond me, since everything needed is already included within its own distribution of gcc. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include and lib search paths for mingw-64
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 installation structure ? This is a side-effect of the way gcc is built. It's possible to mitigate this by 1) Cross-compiling gcc (instead of compiling it on Windows) from Cygwin or a GNU system 2) Patching gcc to throw away include and lib paths that start with '/' when running on Windows. If not cross-compiled, gcc will have an absolute DOS path in its search list (this is mitigated by building it in a randomly-named staging directory deep in the temp tree to ensure that this has near-zero probability of acting up in real life); some people settle for that. Thanks for the info. I guess the question then is why gcc is built in such backwards ( to this programmer ) way. Hardcoding absolute paths, in programing circa the year 2015, seems abolutely lunacy. But I don't expect an answer to why gcc works the way it does on this mailing list. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include and lib search paths for mingw-64
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 instead of searching for include files and libraries relative to its installation structure ? This is a side-effect of the way gcc is built. It's possible to mitigate this by 1) Cross-compiling gcc (instead of compiling it on Windows) from Cygwin or a GNU system 2) Patching gcc to throw away include and lib paths that start with '/' when running on Windows. If not cross-compiled, gcc will have an absolute DOS path in its search list (this is mitigated by building it in a randomly-named staging directory deep in the temp tree to ensure that this has near-zero probability of acting up in real life); some people settle for that. Thanks for the info. I guess the question then is why gcc is built in such backwards ( to this programmer ) way. Hardcoding absolute paths, in programing circa the year 2015, seems abolutely lunacy. But I don't expect an answer to why gcc works the way it does on this mailing list. gcc has a POSIX-centric (and complex) buildsystem. Hardcoding sysroot paths is not considered a deadly sin there. 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 I appreciate, and it is done much better than mingw ever did it. Why not then set the paths to your include files and libraries to relative places within the distribution ? This would make each mingw-64 release completely self sufficient within itself and easily allow multiple mingw-64 releases to coexist and be used by the end-user. Has this ever even been discussed by mingw-64 developers preparing releases ? Because I cannot believe in this day and age that any programmer thinks that harcoding absolute paths, never mind the same absolute path with each new version, can be advantageous to the releases of any product, whether it be mingw-64 or otherwise. Probably the reason why gcc on Linux hardcodes absolute paths is because gcc is distributed as a separate package than the C standard library and the C++ standard library. But this is not the case with mingw-64 as a product installed on Windows. So why not do it the right way and make it even easier for end-users to use your product especially if they wish to run and test multiple versions. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include and lib search paths for mingw-64
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 all part of any mingw-64 distribution. That I appreciate, and it is done much better than mingw ever did it. Why not then set the paths to your include files and libraries to relative places within the distribution ? As a side note, the TDM-GCC[1] toolchains all include a patch to effectively make all paths relative. Unfortunately this greatly complicates the process of building GCC itself, which may be part of the reason why it's not been standardized yet. The limitation of gcc's hardcoded absolute paths should never have been propagated to mingw-64 ( or mingw originally ). I can understand it makes building gcc for Windows more difficult to have paths relative to the installation but hardcoded absolute paths are really an archaism that the computer programming world needs to eliminate if there is no good reason for it and it is merely being propagated by rote. 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. 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. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Include and lib search paths for mingw-64
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 in their build for c:\mingw instead of searching for include files and libraries relative to its installation structure ? This is a side-effect of the way gcc is built. It's possible to mitigate this by 1) Cross-compiling gcc (instead of compiling it on Windows) from Cygwin or a GNU system 2) Patching gcc to throw away include and lib paths that start with '/' when running on Windows. If not cross-compiled, gcc will have an absolute DOS path in its search list (this is mitigated by building it in a randomly-named staging directory deep in the temp tree to ensure that this has near-zero probability of acting up in real life); some people settle for that. Thanks for the info. I guess the question then is why gcc is built in such backwards ( to this programmer ) way. Hardcoding absolute paths, in programing circa the year 2015, seems abolutely lunacy. But I don't expect an answer to why gcc works the way it does on this mailing list. gcc has a POSIX-centric (and complex) buildsystem. Hardcoding sysroot paths is not considered a deadly sin there. 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 Windows do you typically need to have precompiled copies installed based on the user's preferences. Then on Windows mingw-64 would be foolish to continue to hardcode the same absolute paths each time rather than have the paths be relative to the distribution being installed. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Out of memory for cc1plus
On 12/24/2014 11:29 PM, Óscar Fuentes wrote: Edward Diener eldlistmaili...@tropicsoft.com writes: I am seeing an out of memory message of: cc1plus.exe: out of memory allocating 65536 bytes when compiling code using mingw-64 from gcc-4.8.1, gcc-4.8.2, gcc-4.8.3, gcc-4.9.0, and gcc-4.9.1. Nor is this just a mingw-64 problem as I am seeing the same error when compiling the same code with mingw and gcc-4.8.1. Strangely this error does not occur when compiling the exact same code using versions from mingw of gcc-4.3.0 through gcc-4.7.2. The code is heavily preprocessor code for my VMD library, which also depends on the Boost PP library. In other words the code is almost entirely involved with testing macro expansions in the libray. As a piece of related information, which may not be very relevant, the latest clang and versions of vc++ from vc++8 through vc++12 do not exhibit any out of memory errors. See if http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 applies to your case. If the answer is affirmative, passing -ftrack-macro-expansion=0 will reduce memory usage. The -ftrack-macro-expansion=0 compiler flag completely solved the problem. Thank you very much ! -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Out of memory for cc1plus
I am seeing an out of memory message of: cc1plus.exe: out of memory allocating 65536 bytes when compiling code using mingw-64 from gcc-4.8.1, gcc-4.8.2, gcc-4.8.3, gcc-4.9.0, and gcc-4.9.1. Nor is this just a mingw-64 problem as I am seeing the same error when compiling the same code with mingw and gcc-4.8.1. Strangely this error does not occur when compiling the exact same code using versions from mingw of gcc-4.3.0 through gcc-4.7.2. The code is heavily preprocessor code for my VMD library, which also depends on the Boost PP library. In other words the code is almost entirely involved with testing macro expansions in the libray. As a piece of related information, which may not be very relevant, the latest clang and versions of vc++ from vc++8 through vc++12 do not exhibit any out of memory errors. It seems gcc has regressed in some way starting with version 4.8.1 in its handling of memory allocation. Is this a known problem with with these latest gcc releases ? Is anyone involved with gcc trying to fix the problem if it is known ? Or might this just be a problem in Windows with mingw and mingw-64 implementations of the latest gcc ? The code in question is highly complicated, as befits an advanced macro programming library like VMD, so it would be very difficult to reproduce it in some simpler form. But the fact that it occurs in the latest version of gcc-4 but not in the earlier versions suggests something that has been done wrong and might already be known about. I am compiling under Windows 7 Ultimate with 8 GB of real memory, so I do not think this has anything to do with my hardware itself. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Debug application built with mingw64
How do I debug a command line application built with Mingw64 on Windows ? Is there a gdb debugger that works natively under Windows or do I need something else ? -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
