From: Andi M. <and...@gm...> - 2012-08-09 08:36:52
|
Hi, there is a library I work with ( http://polycode.org/ ) which many of the other users of the library have had difficulty compiling. I have been trying to put together a package of statically built versions of the library along with build scripts, to assist these users. There is a complication however, I don't have a copy of Windows. Therefore, when I build the Windows version of the library, I build using MinGW 4.3.0 (or gcc --version says it's 4.3.0, anyway), because this is the most recent version of MinGW I have been able to find a binary installer of for my OS X machine ( http://crossgcc.rts-software.org/doku.php ). I expect this means that when I give Windows users their static library, they will have to build against it using MinGW, because of the MSVC name mangling issue. However, when I actually went and built said static library, and gave it to a tester, I ran into a second problem. My Windows tester installed Mingw and MSYS by going to the mingw website and clicking the "Looking for the latest version?" link at the top of http://sourceforge.net/projects/mingw/files/ . When they ran the Makefile I supplied them (a Makefile which has been tested and works on *my* machine), they got an enormous number of linker errors ( http://dl.dropbox.com/u/837167/errors.txt ), complaining of the same missing 3 or 4 symbols over and over, things like "undefined reference to `___gxx_personality_sj0". When I checked google for these errors, I found many links explaining that these errors are symptomatic of trying to link against a library built with mingw, using a different version of mingw. I asked my tester to run gcc --version and it printed 4.7.0. I'm not sure how to proceed from here. My first impulse is to get the tester to go back and install MinGW 4.3.0 on their machine. But we can't figure out where to even obtain that. The sourceforge binaries repository contains a great many files with cryptic names and it *looks* (?) like most of the packages other than the "click here for newest version" link aren't an installer or anything but are something like standalone binaries for gcc. (There is this mingw-get thing but we're not sure if that can be used to obtain a whole 4.3.0 toolchain.) What I am trying to figure out is: 1. Is there some way, with my MinGW 4.3.0 install, I can create a library that a user of later MinGWs (such as 4.7.0...?) can link against? Is the problem really that you can't link across MinGW versions *at all* (I feel like it would be surprising if this were the case), or is it just that I need to package in a particular version of libstdc++ or something? 2. If I really must get my users to compile with MinGW 4.3.0, how can I instruct them in getting this? Remember that my main problem is I am trying to give directions to people who aren't really master coders or anything. These are very specifically people who couldn't figure out how to use CMake and therefore need me to compile the library for them. So if I'm to do this at all, I need to be able to give them a no-brainer flow that's like-- download this package A and run the installer, download this package B and run the installer, download my package to this directory, open this window, type "make". Is there hope? |
From: JonY <jo...@us...> - 2012-08-09 09:22:46
Attachments:
signature.asc
|
On 8/9/2012 16:36, Andi McClure wrote: > Hi, there is a library I work with ( http://polycode.org/ ) which many of > the other users of the library have had difficulty compiling. I have been > trying to put together a package of statically built versions of the > library along with build scripts, to assist these users. There is a > complication however, I don't have a copy of Windows. Therefore, when I > build the Windows version of the library, I build using MinGW 4.3.0 (or gcc > --version says it's 4.3.0, anyway), because this is the most recent version > of MinGW I have been able to find a binary installer of for my OS X machine > ( http://crossgcc.rts-software.org/doku.php ). I expect this means that > when I give Windows users their static library, they will have to build > against it using MinGW, because of the MSVC name mangling issue. > > However, when I actually went and built said static library, and gave it to > a tester, I ran into a second problem. My Windows tester installed Mingw > and MSYS by going to the mingw website and clicking the "Looking for the > latest version?" link at the top of > http://sourceforge.net/projects/mingw/files/ . When they ran the Makefile I > supplied them (a Makefile which has been tested and works on *my* machine), > they got an enormous number of linker errors ( > http://dl.dropbox.com/u/837167/errors.txt ), complaining of the same > missing 3 or 4 symbols over and over, things like "undefined reference to > `___gxx_personality_sj0". When I checked google for these errors, I found > many links explaining that these errors are symptomatic of trying to link > against a library built with mingw, using a different version of mingw. I > asked my tester to run gcc --version and it printed 4.7.0. > Different version here means different compiler setup. Your libraries seem to be built with SJLJ exception handling in mind, where as the upstream compiler uses DWARF-2. > I'm not sure how to proceed from here. My first impulse is to get the > tester to go back and install MinGW 4.3.0 on their machine. But we can't > figure out where to even obtain that. The sourceforge binaries repository > contains a great many files with cryptic names and it *looks* (?) like most > of the packages other than the "click here for newest version" link aren't > an installer or anything but are something like standalone binaries for > gcc. (There is this mingw-get thing but we're not sure if that can be used > to obtain a whole 4.3.0 toolchain.) > You could easily setup a cross compiler on your system, just make sure to use exactly the same GCC configure and build option with additional --build --host --target. > What I am trying to figure out is: > > 1. Is there some way, with my MinGW 4.3.0 install, I can create a library > that a user of later MinGWs (such as 4.7.0...?) can link against? Is the > problem really that you can't link across MinGW versions *at all* (I feel > like it would be surprising if this were the case), or is it just that I > need to package in a particular version of libstdc++ or something? > You can't, C++ is a fickle language if you want to use different compilers, you must have the exact library and compiler configuration for your entire build, from preprocessor down to link libraries and runtime DLLs if any. The underlying implementation is never defined by the standard. The easiest way is to just distribute in source, obviously, it might not do for all your audience. > 2. If I really must get my users to compile with MinGW 4.3.0, how can I > instruct them in getting this? Remember that my main problem is I am trying > to give directions to people who aren't really master coders or anything. > These are very specifically people who couldn't figure out how to use CMake > and therefore need me to compile the library for them. So if I'm to do this > at all, I need to be able to give them a no-brainer flow that's like-- > download this package A and run the installer, download this package B and > run the installer, download my package to this directory, open this window, > type "make". You could make a copy of your own developer environment or you could make your own mingw cross compiler as detailed above, or you could download and run the latest mingw GCC under wine to build your libraries. |
From: Earnie B. <ea...@us...> - 2012-08-09 11:45:53
|
On Thu, Aug 9, 2012 at 4:36 AM, Andi McClure wrote: > Hi, there is a library I work with ( http://polycode.org/ ) which many of > the other users of the library have had difficulty compiling. I have been > trying to put together a package of statically built versions of the library > along with build scripts, to assist these users. There is a complication > however, I don't have a copy of Windows. Therefore, when I build the Windows > version of the library, I build using MinGW 4.3.0 (or gcc --version says > it's 4.3.0, anyway), because this is the most recent version of MinGW I have > been able to find a binary installer of for my OS X machine ( > http://crossgcc.rts-software.org/doku.php ). I expect this means that when I > give Windows users their static library, they will have to build against it > using MinGW, because of the MSVC name mangling issue. > > However, when I actually went and built said static library, and gave it to > a tester, I ran into a second problem. My Windows tester installed Mingw and > MSYS by going to the mingw website and clicking the "Looking for the latest > version?" link at the top of http://sourceforge.net/projects/mingw/files/ . > When they ran the Makefile I supplied them (a Makefile which has been tested > and works on *my* machine), they got an enormous number of linker errors ( > http://dl.dropbox.com/u/837167/errors.txt ), complaining of the same missing > 3 or 4 symbols over and over, things like "undefined reference to > `___gxx_personality_sj0". When I checked google for these errors, I found > many links explaining that these errors are symptomatic of trying to link > against a library built with mingw, using a different version of mingw. I > asked my tester to run gcc --version and it printed 4.7.0. Yes, this would be an issue since 4.7.0 introduced ABI incompatibility. The earliest version of GCC-4 I see we distributed was 4.5.2. Have your tester install it to test it. mingw-get install --reinstall "gcc=4.5.*" > > I'm not sure how to proceed from here. My first impulse is to get the tester > to go back and install MinGW 4.3.0 on their machine. But we can't figure out > where to even obtain that. The sourceforge binaries repository contains a > great many files with cryptic names and it *looks* (?) like most of the > packages other than the "click here for newest version" link aren't an > installer or anything but are something like standalone binaries for gcc. > (There is this mingw-get thing but we're not sure if that can be used to > obtain a whole 4.3.0 toolchain.) > > What I am trying to figure out is: > > 1. Is there some way, with my MinGW 4.3.0 install, I can create a library > that a user of later MinGWs (such as 4.7.0...?) can link against? Is the > problem really that you can't link across MinGW versions *at all* (I feel > like it would be surprising if this were the case), or is it just that I > need to package in a particular version of libstdc++ or something? > No, there are ABI incompatibilities. > 2. If I really must get my users to compile with MinGW 4.3.0, how can I > instruct them in getting this? Remember that my main problem is I am trying > to give directions to people who aren't really master coders or anything. > These are very specifically people who couldn't figure out how to use CMake > and therefore need me to compile the library for them. So if I'm to do this > at all, I need to be able to give them a no-brainer flow that's like-- > download this package A and run the installer, download this package B and > run the installer, download my package to this directory, open this window, > type "make". > It is better for you to build or find someone to do it for you for your version of OS a MinGW cross compiler. gcc-4.3 is rather old now and there have been many improvements. > Is there hope? Yes, there is hope and it lives in you. http://bit.ly/ONuTAn -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Andi M. <and...@gm...> - 2012-08-11 19:31:53
|
Ernie, JonY, thanks, this is very helpful! I do have a few followup questions. 1. As you say, it does look like if I really want to do this I'll need to compile my own MinGW-- the last time I tried that myself it proved very difficult, but I guess I can try. I still run into the same question though: How do I maximize compatibility? Asked another way, if I somehow compile 4.7.0 for Mac or Linux, what range of versions going into the future can I reasonably expect this binary to continue to link against? 2. Checking, I find on my Ubuntu VM I am able to install version 4.6.3 of "mingw32-w64" via an easily accessible package. As I understand, w64 is a fork of mingw32. Should I expect static libraries compiled with 4.6.3 of mingw32-w64 to be link-compatible with static libraries compiled with 4.6.3 mainline? Should I in general be able to expect that 32-bit binaries created by mingw32 mainline and w64 are link-compatible if they use the same version of GCC (and are on the same side of the sjlj/dwarf2 split)? 3. I recognize this last thing is probably a stupid question. Although surely there are many ABI compatibility issues to be concerned about, the main one I seem to be running into is the sjlj vs dwarf2 split on exceptions. However, this is odd to me because I don't feel convinced I even need exceptions. What I am trying to do is give people a way to compile a program A I supply, which links against a static library B I supply, which itself links in some static libraries C,D, etc. C and D (stuff like libpng) do contain try/catch, but A and B do not. When I look at the error list I linked earlier, the errors involving exception linking all seem to be in the static sub-libraries, which contain and don't find those sjlj support symbols. Do I have any way to cheat and slip past the exception issue using -fno-exceptions? Or does sjlj vs dwarf2 matter even when compiling with -fno-exceptions? Thanks! On Thu, Aug 9, 2012 at 4:45 AM, Earnie Boyd <ea...@us...>wrote: > On Thu, Aug 9, 2012 at 4:36 AM, Andi McClure wrote: > > Hi, there is a library I work with ( http://polycode.org/ ) which many > of > > the other users of the library have had difficulty compiling. I have been > > trying to put together a package of statically built versions of the > library > > along with build scripts, to assist these users. There is a complication > > however, I don't have a copy of Windows. Therefore, when I build the > Windows > > version of the library, I build using MinGW 4.3.0 (or gcc --version says > > it's 4.3.0, anyway), because this is the most recent version of MinGW I > have > > been able to find a binary installer of for my OS X machine ( > > http://crossgcc.rts-software.org/doku.php ). I expect this means that > when I > > give Windows users their static library, they will have to build against > it > > using MinGW, because of the MSVC name mangling issue. > > > > However, when I actually went and built said static library, and gave it > to > > a tester, I ran into a second problem. My Windows tester installed Mingw > and > > MSYS by going to the mingw website and clicking the "Looking for the > latest > > version?" link at the top of > http://sourceforge.net/projects/mingw/files/ . > > When they ran the Makefile I supplied them (a Makefile which has been > tested > > and works on *my* machine), they got an enormous number of linker errors > ( > > http://dl.dropbox.com/u/837167/errors.txt ), complaining of the same > missing > > 3 or 4 symbols over and over, things like "undefined reference to > > `___gxx_personality_sj0". When I checked google for these errors, I found > > many links explaining that these errors are symptomatic of trying to link > > against a library built with mingw, using a different version of mingw. I > > asked my tester to run gcc --version and it printed 4.7.0. > > Yes, this would be an issue since 4.7.0 introduced ABI > incompatibility. The earliest version of GCC-4 I see we distributed > was 4.5.2. Have your tester install it to test it. > > mingw-get install --reinstall "gcc=4.5.*" > > > > > I'm not sure how to proceed from here. My first impulse is to get the > tester > > to go back and install MinGW 4.3.0 on their machine. But we can't figure > out > > where to even obtain that. The sourceforge binaries repository contains a > > great many files with cryptic names and it *looks* (?) like most of the > > packages other than the "click here for newest version" link aren't an > > installer or anything but are something like standalone binaries for gcc. > > (There is this mingw-get thing but we're not sure if that can be used to > > obtain a whole 4.3.0 toolchain.) > > > > What I am trying to figure out is: > > > > 1. Is there some way, with my MinGW 4.3.0 install, I can create a library > > that a user of later MinGWs (such as 4.7.0...?) can link against? Is the > > problem really that you can't link across MinGW versions *at all* (I feel > > like it would be surprising if this were the case), or is it just that I > > need to package in a particular version of libstdc++ or something? > > > > No, there are ABI incompatibilities. > > > 2. If I really must get my users to compile with MinGW 4.3.0, how can I > > instruct them in getting this? Remember that my main problem is I am > trying > > to give directions to people who aren't really master coders or anything. > > These are very specifically people who couldn't figure out how to use > CMake > > and therefore need me to compile the library for them. So if I'm to do > this > > at all, I need to be able to give them a no-brainer flow that's like-- > > download this package A and run the installer, download this package B > and > > run the installer, download my package to this directory, open this > window, > > type "make". > > > > It is better for you to build or find someone to do it for you for > your version of OS a MinGW cross compiler. gcc-4.3 is rather old now > and there have been many improvements. > > > Is there hope? > > Yes, there is hope and it lives in you. > http://bit.ly/ONuTAn > > -- > Earnie > -- https://sites.google.com/site/earnieboyd > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > |
From: JonY <jo...@us...> - 2012-08-12 01:01:34
Attachments:
signature.asc
|
On 8/12/2012 03:31, Andi McClure wrote: > Ernie, JonY, thanks, this is very helpful! I do have a few followup > questions. > > 1. As you say, it does look like if I really want to do this I'll need to > compile my own MinGW-- the last time I tried that myself it proved very > difficult, but I guess I can try. I still run into the same question > though: How do I maximize compatibility? Asked another way, if I somehow > compile 4.7.0 for Mac or Linux, what range of versions going into the > future can I reasonably expect this binary to continue to link against? > Well, the same compiler version of course, provided you used the same exact configuration options. > 2. Checking, I find on my Ubuntu VM I am able to install version 4.6.3 of > "mingw32-w64" via an easily accessible package. As I understand, w64 is a > fork of mingw32. Should I expect static libraries compiled with 4.6.3 of > mingw32-w64 to be link-compatible with static libraries compiled with 4.6.3 > mainline? Should I in general be able to expect that 32-bit binaries > created by mingw32 mainline and w64 are link-compatible if they use the > same version of GCC (and are on the same side of the sjlj/dwarf2 split)? > No, they are not compatible at all, especially the startup objects, the sjlj/dwarf-2 is just another facet of it. Mixing compiled C++ code from different vendors/compilers/version of compilers is just asking for trouble. > 3. I recognize this last thing is probably a stupid question. Although > surely there are many ABI compatibility issues to be concerned about, the > main one I seem to be running into is the sjlj vs dwarf2 split on > exceptions. However, this is odd to me because I don't feel convinced I > even need exceptions. What I am trying to do is give people a way to > compile a program A I supply, which links against a static library B I > supply, which itself links in some static libraries C,D, etc. C and D > (stuff like libpng) do contain try/catch, but A and B do not. When I look > at the error list I linked earlier, the errors involving exception linking > all seem to be in the static sub-libraries, which contain and don't find > those sjlj support symbols. Do I have any way to cheat and slip past the > exception issue using -fno-exceptions? Or does sjlj vs dwarf2 matter even > when compiling with -fno-exceptions? With static linking, yes it matters, you have already mentioned some 3rd party libraries requiring it. Using try catch with -fno-exceptions will generate a compile error. |