This list is closed, nobody may subscribe to it.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(371) |
Oct
(167) |
Nov
(412) |
Dec
(208) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(378) |
Feb
(302) |
Mar
(269) |
Apr
(296) |
May
(306) |
Jun
(381) |
Jul
(346) |
Aug
(315) |
Sep
(195) |
Oct
(216) |
Nov
(280) |
Dec
(227) |
2002 |
Jan
(309) |
Feb
(333) |
Mar
(328) |
Apr
(407) |
May
(517) |
Jun
(519) |
Jul
(400) |
Aug
(580) |
Sep
(1273) |
Oct
(984) |
Nov
(683) |
Dec
(538) |
2003 |
Jan
(578) |
Feb
(454) |
Mar
(312) |
Apr
(366) |
May
(505) |
Jun
(431) |
Jul
(415) |
Aug
(374) |
Sep
(470) |
Oct
(578) |
Nov
(372) |
Dec
(309) |
2004 |
Jan
(308) |
Feb
(247) |
Mar
(372) |
Apr
(413) |
May
(333) |
Jun
(323) |
Jul
(269) |
Aug
(239) |
Sep
(469) |
Oct
(383) |
Nov
(400) |
Dec
(332) |
2005 |
Jan
(411) |
Feb
(363) |
Mar
(346) |
Apr
(316) |
May
(275) |
Jun
(248) |
Jul
(396) |
Aug
(396) |
Sep
(279) |
Oct
(340) |
Nov
(319) |
Dec
(218) |
2006 |
Jan
(317) |
Feb
(263) |
Mar
(304) |
Apr
(296) |
May
(209) |
Jun
(349) |
Jul
(246) |
Aug
(198) |
Sep
(174) |
Oct
(138) |
Nov
(201) |
Dec
(270) |
2007 |
Jan
(223) |
Feb
(182) |
Mar
(350) |
Apr
(350) |
May
(259) |
Jun
(221) |
Jul
(299) |
Aug
(465) |
Sep
(356) |
Oct
(265) |
Nov
(417) |
Dec
(225) |
2008 |
Jan
(421) |
Feb
(327) |
Mar
(219) |
Apr
(389) |
May
(375) |
Jun
(262) |
Jul
(215) |
Aug
(289) |
Sep
(257) |
Oct
(383) |
Nov
(237) |
Dec
(209) |
2009 |
Jan
(232) |
Feb
(327) |
Mar
(306) |
Apr
(251) |
May
(146) |
Jun
(247) |
Jul
(302) |
Aug
(252) |
Sep
(263) |
Oct
(376) |
Nov
(270) |
Dec
(244) |
2010 |
Jan
(225) |
Feb
(184) |
Mar
(300) |
Apr
(290) |
May
(275) |
Jun
(535) |
Jul
(192) |
Aug
(237) |
Sep
(304) |
Oct
(142) |
Nov
(384) |
Dec
(186) |
2011 |
Jan
(305) |
Feb
(337) |
Mar
(331) |
Apr
(318) |
May
(306) |
Jun
(299) |
Jul
(205) |
Aug
(271) |
Sep
(232) |
Oct
(179) |
Nov
(252) |
Dec
(216) |
2012 |
Jan
(195) |
Feb
(268) |
Mar
(142) |
Apr
(226) |
May
(203) |
Jun
(132) |
Jul
(211) |
Aug
(429) |
Sep
(289) |
Oct
(291) |
Nov
(182) |
Dec
(188) |
2013 |
Jan
(205) |
Feb
(259) |
Mar
(224) |
Apr
(125) |
May
(295) |
Jun
(181) |
Jul
(209) |
Aug
(167) |
Sep
(330) |
Oct
(212) |
Nov
(95) |
Dec
(114) |
2014 |
Jan
(40) |
Feb
(63) |
Mar
(62) |
Apr
(65) |
May
(82) |
Jun
(105) |
Jul
(56) |
Aug
(175) |
Sep
(79) |
Oct
(49) |
Nov
(51) |
Dec
(47) |
2015 |
Jan
(26) |
Feb
(69) |
Mar
(82) |
Apr
(55) |
May
(35) |
Jun
(57) |
Jul
(54) |
Aug
(56) |
Sep
(25) |
Oct
(21) |
Nov
(8) |
Dec
(27) |
2016 |
Jan
(49) |
Feb
(44) |
Mar
(132) |
Apr
(39) |
May
(39) |
Jun
(49) |
Jul
(70) |
Aug
(43) |
Sep
(69) |
Oct
(79) |
Nov
(65) |
Dec
(32) |
2017 |
Jan
(99) |
Feb
(88) |
Mar
(42) |
Apr
(47) |
May
(56) |
Jun
|
Jul
(79) |
Aug
(9) |
Sep
(29) |
Oct
(4) |
Nov
|
Dec
(12) |
2018 |
Jan
(45) |
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Eli Z. <el...@gn...> - 2018-02-05 16:55:19
|
> From: Budi <bud...@gm...> > Date: Mon, 5 Feb 2018 06:00:59 +0700 > > zlib-1.2.11 > xz-5.0.4 > libpng-1.5.30 > giflib-5.1.4 > jpeg-9c > jbigkit-2.0 > libtiff-3.9.5 > libwebp-0.6.1 > > all were succesfully compiled except in commanding make for: libtiff-3.9.5 > > $ make > ... > > *** Warning: This system cannot link to static lib archive > D:/MSYS/mingw64/lib/libjpeg.la. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have > ... > And also failed on commanding make when building Leptonica : > ... > CC ... > CCLD liblept.la > > *** Warning: This system cannot link to static lib archive > D:/msys/mingw64/lib/libjpeg.la. You need to build jpeg such that the build produces a DLL, not just a static library. (Besides, the mingw64 thing leads me to a guess that you are using MinGW64, which is not the MinGW supported by this mailing list. But that doesn't invalidate my suggestion above, I hope.) |
From: Budi <bud...@gm...> - 2018-02-04 23:01:08
|
I tried to build Leptonica 1.74.4 on MINGW64 under MSYS2, so tried to build its dependencies by instruction in: http://www.sk-spell.sk.cx/compiling-leptonica-and-tesseract-ocr-with-mingwmsys instead of these older versions I did it with mostly the newer ones, here are what I've built of them: zlib-1.2.11 xz-5.0.4 libpng-1.5.30 giflib-5.1.4 jpeg-9c jbigkit-2.0 libtiff-3.9.5 libwebp-0.6.1 all were succesfully compiled except in commanding make for: libtiff-3.9.5 $ make ... *** Warning: This system cannot link to static lib archive D:/MSYS/mingw64/lib/libjpeg.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have ... And also failed on commanding make when building Leptonica : ... CC ... CCLD liblept.la *** Warning: This system cannot link to static lib archive D:/msys/mingw64/lib/libjpeg.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. .libs/jpegio.o: In function `jpeg_error_catch_all_1': D:\MSYS\usr\src\leptonica\src/jpegio.c:1171: undefined reference to `jpeg_destroy' .libs/jpegio.o: In function `jpeg_error_catch_all_2': D:\MSYS\usr\src\leptonica\src/jpegio.c:1191: undefined reference to `jpeg_destroy' .libs/jpegio.o: In function `pixReadStreamJpeg': D:\MSYS\usr\src\leptonica\src/jpegio.c:305: undefined reference to `jpeg_std_error' D:\MSYS\usr\src\leptonica\src/jpegio.c:315: undefined reference to `jpeg_CreateDecompress' D:\MSYS\usr\src\leptonica\src/jpegio.c:316: undefined reference to `jpeg_stdio_src' D:\MSYS\usr\src\leptonica\src/jpegio.c:317: undefined reference to `jpeg_read_header' D:\MSYS\usr\src\leptonica\src/jpegio.c:320: undefined reference to `jpeg_calc_output_dimensions' D:\MSYS\usr\src\leptonica\src/jpegio.c:359: undefined reference to `jpeg_start_decompress' D:\MSYS\usr\src\leptonica\src/jpegio.c:389: undefined reference to `jpeg_read_scanlines' D:\MSYS\usr\src\leptonica\src/jpegio.c:474: undefined reference to `jpeg_finish_decompress' D:\MSYS\usr\src\leptonica\src/jpegio.c:475: undefined reference to `jpeg_destroy_decompress' D:\MSYS\usr\src\leptonica\src/jpegio.c:392: undefined reference to `jpeg_destroy_decompress' D:\MSYS\usr\src\leptonica\src/jpegio.c:363: undefined reference to `jpeg_start_decompress' D:\MSYS\usr\src\leptonica\src/jpegio.c:355: undefined reference to `jpeg_start_decompress' .libs/jpegio.o: In function `freadHeaderJpeg': D:\MSYS\usr\src\leptonica\src/jpegio.c:575: undefined reference to `jpeg_std_error' D:\MSYS\usr\src\leptonica\src/jpegio.c:582: undefined reference to `jpeg_CreateDecompress' D:\MSYS\usr\src\leptonica\src/jpegio.c:583: undefined reference to `jpeg_stdio_src' D:\MSYS\usr\src\leptonica\src/jpegio.c:584: undefined reference to `jpeg_read_header' D:\MSYS\usr\src\leptonica\src/jpegio.c:585: undefined reference to `jpeg_calc_output_dimensions' D:\MSYS\usr\src\leptonica\src/jpegio.c:596: undefined reference to `jpeg_destroy_decompress' .libs/jpegio.o: In function `fgetJpegResolution': D:\MSYS\usr\src\leptonica\src/jpegio.c:635: undefined reference to `jpeg_std_error' D:\MSYS\usr\src\leptonica\src/jpegio.c:642: undefined reference to `jpeg_CreateDecompress' D:\MSYS\usr\src\leptonica\src/jpegio.c:643: undefined reference to `jpeg_stdio_src' D:\MSYS\usr\src\leptonica\src/jpegio.c:644: undefined reference to `jpeg_read_header' D:\MSYS\usr\src\leptonica\src/jpegio.c:656: undefined reference to `jpeg_destroy_decompress' .libs/jpegio.o: In function `fgetJpegComment': D:\MSYS\usr\src\leptonica\src/jpegio.c:691: undefined reference to `jpeg_std_error' D:\MSYS\usr\src\leptonica\src/jpegio.c:701: undefined reference to `jpeg_CreateDecompress' D:\MSYS\usr\src\leptonica\src/jpegio.c:702: undefined reference to `jpeg_set_marker_processor' D:\MSYS\usr\src\leptonica\src/jpegio.c:703: undefined reference to `jpeg_stdio_src' D:\MSYS\usr\src\leptonica\src/jpegio.c:704: undefined reference to `jpeg_read_header' D:\MSYS\usr\src\leptonica\src/jpegio.c:708: undefined reference to `jpeg_destroy_decompress' .libs/jpegio.o: In function `pixWriteStreamJpeg': D:\MSYS\usr\src\leptonica\src/jpegio.c:839: undefined reference to `jpeg_std_error' D:\MSYS\usr\src\leptonica\src/jpegio.c:849: undefined reference to `jpeg_CreateCompress' D:\MSYS\usr\src\leptonica\src/jpegio.c:850: undefined reference to `jpeg_stdio_dest' D:\MSYS\usr\src\leptonica\src/jpegio.c:866: undefined reference to `jpeg_set_defaults' D:\MSYS\usr\src\leptonica\src/jpegio.c:882: undefined reference to `jpeg_set_quality' D:\MSYS\usr\src\leptonica\src/jpegio.c:903: undefined reference to `jpeg_start_compress' D:\MSYS\usr\src\leptonica\src/jpegio.c:913: undefined reference to `jpeg_write_marker' D:\MSYS\usr\src\leptonica\src/jpegio.c:946: undefined reference to `jpeg_write_scanlines' D:\MSYS\usr\src\leptonica\src/jpegio.c:948: undefined reference to `jpeg_finish_compress' D:\MSYS\usr\src\leptonica\src/jpegio.c:952: undefined reference to `jpeg_destroy_compress' D:\MSYS\usr\src\leptonica\src/jpegio.c:934: undefined reference to `jpeg_write_scanlines' D:\MSYS\usr\src\leptonica\src/jpegio.c:884: undefined reference to `jpeg_simple_progression' .libs/libversions.o: In function `getImagelibVersions': D:\MSYS\usr\src\leptonica\src/libversions.c:126: undefined reference to `jpeg_std_error' collect2.exe: error: ld returned 1 exit status make[2]: *** [Makefile:534: liblept.la] Error 1 make[2]: Leaving directory '/d/MSYS/usr/src/leptonica/src' make[1]: *** [Makefile:475: all-recursive] Error 1 make[1]: Leaving directory '/d/MSYS/usr/src/leptonica' make: *** [Makefile:384: all] Error 2 What's actually happened in the building failure ? which one actually complained, gcc or ld.exe ? I scan the jpeg-9c, the libjpeg.h and all its requirement are existing and complete Please help me.. I really need the Leptonica built available for myself Thanks so much in advance.. |
From: Steve M. <st...@ma...> - 2018-02-04 19:24:03
|
You are exactly right. I don;t know how to create a shortcut on the start menu. I'll do a Google search. Thanks Steve <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Sun, Feb 4, 2018 at 11:26 AM, Eli Zaretskii <el...@gn...> wrote: > From 12th February 2018, this list will be closed to posting of new > message threads. > Please subscribe to, and redirect new threads to > Min...@li... instead, with immediate effect. > (See https://lists.osdn.me/mailman/listinfo/mingw-users for subscription > information). > > From: Steve Maguire <st...@ma...> > > Date: Sat, 3 Feb 2018 20:46:48 -0600 > > > > I have just installed mingw. Reading through the Graphical User > Interface Installer instructions I got confused. > > In the section entitled After Installing You Should ... there is a list > of 5 instructions that I believe I followed. > > Then there is another paragraph: > > > > Additionally, if you have installed MSYS, you are advised to create a > start menu "MinGW Shell" shortcut > > in your "Start\Programs\MinGW" folder, (which you may also need to > create); this should invoke the > > C:\MinGW\msys\1.0\msys.bat script, which is installed as a component of > MSYS; (if you installed to an > > alternative directory, you should adjust the C:\MinGW prefix > accordingly). > > > > Having worked with Linux I have some familiarity with shortcuts in that > environment, but not in Win10. I find > > the reference to the "Start\Programs\MinGW" folder very confusing. In > a Linux environment I suppose Start > > could be a folder in root, in Win10 this might be a subdirectory to > something, but I can't figure out what. I find > > the msys.bat script exactly where the paragraph tells me to look for it, > but I am at a lose as to how to use it. > > > > I suppose that since these instructions have been around for years, > there have been others potentially as > > confused as I am, who blundered onto the correct approach. If this > query goes unanswered I suppose I will > > too. > > > > But I'd like to understand what was said to me. > > I guess you are saying that you don't know how to add shortcuts to > your Start menu on Windows 10, is that right? Because that's what the > instruction tell you; you can disregard the details of how/where a > shortcut should be created, and just follow the steps for creating a > Start shortcut that fits your Windows version. The only important > part is that the shortcut should invoke the msys.bat script, as > mentioned above. > > You should be able to find out how to create a Start menu shortcut on > Windows 10 by googling, I think. (I don't have Windows 10, so I > cannot tell you that.) > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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: Eli Z. <el...@gn...> - 2018-02-04 17:26:20
|
> From: Steve Maguire <st...@ma...> > Date: Sat, 3 Feb 2018 20:46:48 -0600 > > I have just installed mingw. Reading through the Graphical User Interface Installer instructions I got confused. > In the section entitled After Installing You Should ... there is a list of 5 instructions that I believe I followed. > Then there is another paragraph: > > Additionally, if you have installed MSYS, you are advised to create a start menu "MinGW Shell" shortcut > in your "Start\Programs\MinGW" folder, (which you may also need to create); this should invoke the > C:\MinGW\msys\1.0\msys.bat script, which is installed as a component of MSYS; (if you installed to an > alternative directory, you should adjust the C:\MinGW prefix accordingly). > > Having worked with Linux I have some familiarity with shortcuts in that environment, but not in Win10. I find > the reference to the "Start\Programs\MinGW" folder very confusing. In a Linux environment I suppose Start > could be a folder in root, in Win10 this might be a subdirectory to something, but I can't figure out what. I find > the msys.bat script exactly where the paragraph tells me to look for it, but I am at a lose as to how to use it. > > I suppose that since these instructions have been around for years, there have been others potentially as > confused as I am, who blundered onto the correct approach. If this query goes unanswered I suppose I will > too. > > But I'd like to understand what was said to me. I guess you are saying that you don't know how to add shortcuts to your Start menu on Windows 10, is that right? Because that's what the instruction tell you; you can disregard the details of how/where a shortcut should be created, and just follow the steps for creating a Start shortcut that fits your Windows version. The only important part is that the shortcut should invoke the msys.bat script, as mentioned above. You should be able to find out how to create a Start menu shortcut on Windows 10 by googling, I think. (I don't have Windows 10, so I cannot tell you that.) |
From: Greg J. <gv...@gm...> - 2018-02-04 09:38:25
|
That seems to refer to the start menu, much more obvious until windows 8 and later makes it look like a phone. You can just make a "link" shortcut on the desktop (shift ctrl > move from explorer shell to desktop<) . On Sat, Feb 3, 2018 at 6:46 PM, Steve Maguire <st...@ma...> wrote: > From 12th February 2018, this list will be closed to posting of new > message threads. > Please subscribe to, and redirect new threads to > Min...@li... instead, with immediate effect. > (See https://lists.osdn.me/mailman/listinfo/mingw-users for subscription > information). > I have just installed mingw. Reading through the Graphical User Interface > Installer instructions I got confused. In the section entitled After > Installing You Should ... there is a list of 5 instructions that I believe > I followed. Then there is another paragraph: > > Additionally, if you have installed MSYS <http://www.mingw.org/wiki/MSYS>, > you are advised to create a start menu "MinGW Shell" shortcut in your > "Start\Programs\MinGW" folder, (which you may also need to create); this > should invoke the C:\MinGW\msys\1.0\msys.bat script, which is installed as > a component of MSYS <http://www.mingw.org/wiki/MSYS>; (if you installed > to an alternative directory, you should adjust the C:\MinGW prefix > accordingly). > > Having worked with Linux I have some familiarity with shortcuts in that > environment, but not in Win10. I find the reference to the "Start\Programs\MinGW" > folder very confusing. In a Linux environment I suppose Start could be a > folder in root, in Win10 this might be a subdirectory to something, but I > can't figure out what. I find the msys.bat script exactly where the > paragraph tells me to look for it, but I am at a lose as to how to use it. > > I suppose that since these instructions have been around for years, there > have been others potentially as confused as I am, who blundered onto the > correct approach. If this query goes unanswered I suppose I will too. > > But I'd like to understand what was said to me. > > Thanks > Steve Maguire > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> > <#m_-5382307338455467363_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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: Steve M. <st...@ma...> - 2018-02-04 02:46:56
|
I have just installed mingw. Reading through the Graphical User Interface Installer instructions I got confused. In the section entitled After Installing You Should ... there is a list of 5 instructions that I believe I followed. Then there is another paragraph: Additionally, if you have installed MSYS <http://www.mingw.org/wiki/MSYS>, you are advised to create a start menu "MinGW Shell" shortcut in your "Start\Programs\MinGW" folder, (which you may also need to create); this should invoke the C:\MinGW\msys\1.0\msys.bat script, which is installed as a component of MSYS <http://www.mingw.org/wiki/MSYS>; (if you installed to an alternative directory, you should adjust the C:\MinGW prefix accordingly). Having worked with Linux I have some familiarity with shortcuts in that environment, but not in Win10. I find the reference to the "Start\Programs\MinGW" folder very confusing. In a Linux environment I suppose Start could be a folder in root, in Win10 this might be a subdirectory to something, but I can't figure out what. I find the msys.bat script exactly where the paragraph tells me to look for it, but I am at a lose as to how to use it. I suppose that since these instructions have been around for years, there have been others potentially as confused as I am, who blundered onto the correct approach. If this query goes unanswered I suppose I will too. But I'd like to understand what was said to me. Thanks Steve Maguire <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> |
From: Keith M. <kei...@us...> - 2018-01-21 22:18:25
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fellow MinGW Users, During 2017, SourceForge.net embarked on a campaign of interference in the administration of our mailing lists, which we, the administrators of MinGW.org, consider to be completely unacceptable. We have invited the SourceForge.net administrators to discuss our concerns about the changes which they have made, but unfortunately, their standpoint has remained unhelpful. Consequently, we have concluded that our continued project hosting on SourceForge.net has become untenable. Having explored possible alternatives, we have found OSDN.net to be both very helpful, and a good fit for our requirements; thus, we have decided that, henceforth, MinGW.org Project hosting will migrate to: https://osdn.net/projects/mingw/ Furthermore, this SourceForge.net hosted mailing list will be closed to new postings, with effect from 12th February 2018; we would encourage you to subscribe, and direct new posts, to our replacement mailing list: https://lists.osdn.me/mailman/listinfo/mingw-users Additionally, if you wish to file bug reports, or feature requests, you should now use our tracking system at: https://osdn.net/ticket/newticket.php?group_id=3917 Obviously, there will be a transitional period, during which you may still need to visit our SourceForge.net files hosting site, to obtain files which you wish to download; indeed, if you are looking for older versions of files, we may choose to leave them only on SourceForge.net in perpetuity, but new releases will henceforth be available only on OSDN.net. We ask for your understanding, during the transition. - -- Cesar, Earnie, and Keith MinGW.org Project Administrators Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJaZRG6AAoJEMCtNsY0flo/RYIP/21+50wYA/ygLPzW9PBL15Dt YRCDAiVa2UaeUsn5OIJTwmtjxf4kmsicSegOfgTPMg2WRZ1euuH+r8B/u7hyX6l2 P6O2JThr9LmMOcGnkea2WPhEeIRYPqC7qN6dHipObMnok7aALLsfX/4qedoKcSIj dAbSfVNBEdDCBW/7xtrJISPzPqRTy2qgCWbEkL8iSOKNDxtRMjAJscPlG4ynCnEb 1GWx/NiBOFrHjE/KYdmtUI/2sys0E5UyfWy6zO6n+zKf21RIEr1TEVdmIiF50Fz8 RWl8ctp2ZhJoJdNfNnayVjMVPshlxgzxKhQZBbPaHV6b8FazRcBBE5JwdZH4N4Bu 1w9xyHxbPZRijx3WeGlmAdudalB3pDXg1UMW42V894ceG8LFvjSao8Z8XGERqBfm UO0WABE1q+k5Xh3KnkjYFkTBxB+3iMyztxTR3Lh8LF96uz2VNYmO1jZfj5beo3OQ 1vV5jjx+4GErnc4ksOJTt9xjhp3mQAvkkLld79LG9jEIagNsAtkNCyw5N7WGebVM uqhS+eZlaapzc4S8diFT8jbp8dfMkVq0B7XyfmuPPRB2zcB5P+Zlyl9Csm/t0o1p ZgTX45YfYPYwRTJvDPSGQPknmoySYY0t5UhTV0Pgnqj/7dpEFpy9H75zxLcpmJCs xEpDhS7uKTggax66eiY5 =RK5P -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2018-01-19 21:07:10
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/01/18 02:53, Earnie via MinGW-users wrote: > Is there a complication when these libraries are embedded in the > GCC source directory tree and built as part of GCC? So trying to > circumvent the madness becomes a bit ludicrous. IIRC, yes there is. I built my Linux hosted mingw32-gcc with GMP, MPFR, MPC, and ISL sources all symlinked into the GCC-6.3.0 tree, and the build ran through to a successful completion. When I then moved on to use that cross-compiler, configuring the same GCC-6.3.0 source tree as a basis for creating a cross-native build for deployment on Win32, the build choked on GMP ... for the very shared vs. static issue which is at play here. The work-around was to build GMP, MPFR, MPC, and ISL out-of-tree, using much the same five step build procedure as I've outlined here. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJaYl30AAoJEMCtNsY0flo/w0sP+weimZpIs0R4JSZfgrZYrgdo 5iebYVtyBCgZS1QQefnRCd+NUKNSpgOCpkauVAeYQ+lm36MDCBflqnRydFM1ddlC 9PPuPyUeZ2Lifeng9co88eTi+GKLv1pJfR09RDyEiBRLqXib6mtHWYcRcccYtbrU E3Xk9Ekzdp6KIiDC9oJKXCXf8RAgA7GAtgq3+WRDUrDh/646CHsI07VyS4ACRpKM NH4PfSAlNee9ycVTs/DX/Zwuq/OYdFP0pgF/cOkzI22GcAIEtXDEAplESkkY0oTE mVqbYmC9PIJEBqauz7mbIubMRS+r5j7ubAkfrJxXx48HGUZDotQfhG+lJnQkJowD O/eBo17mogJ/loN3ccIhjP7za0BccDyCbYJGxEOlQ1CKCTfwS/38Ics+fiCROGo5 OfRKwnRPC2Q6B93UpYo0qPWXFjfSwFxNhRiap8wGP+qPbV3B+Fo85rX2j8HkdimL j9E9ZasyvlZpdBay2BoPOb3E9sYqga3mrDFDxQduq/P2iSPR+uCubBHclKiAwn/V EtHd4YyhGIT7MdudbIGR8XDmfVYZ3c14/dsJPy62HLK+joLHyG7woAIh1y784kFu kvTymGIXFOxL7XX3fiF9fgKP/1vM8Xrz1T0g6eoFMCHBDkAZd5PY4Wn7nu9Vd7rF TO+R4avD10Ii5xZE8tL1 =WROl -----END PGP SIGNATURE----- |
From: Eli Z. <el...@gn...> - 2018-01-19 07:45:50
|
> Date: Thu, 18 Jan 2018 22:20:00 +0000 > From: Keith Marshall via MinGW-users <min...@li...> > Cc: Keith Marshall <kei...@us...> > > Thus, I propose a new user definable _MINGW_CRTIMP_DECLSPEC macro, to > be interpreted by _mingw.h, such that if defined, __USE_CRTIMP will be > defined as 1, otherwise as 0; then we could add conditional code for > both GMP and MPFR, to honour __USE_CRTIMP when __MINGW32__ is defined > by GCC itself. Sounds good to me, thanks. > Supporting something like _MINGW_CRTIMP_DECLSPEC could be useful in its > own right -- i.e. it would give _CRTIMP useful meaning -- my biggest issue with all of this is that developing related patches for GMP and > MPFR, and getting them accepted upstream, could prove more difficult, > and ultimately more time consuming, than just adopting the build method > I've already outlined. Right. |
From: Earnie <ea...@us...> - 2018-01-19 02:53:54
|
On 1/18/2018 5:20 PM, Keith Marshall via MinGW-users wrote: > On 18/01/18 19:17, Eli Zaretskii wrote: >>> Date: Thu, 18 Jan 2018 16:18:36 +0000 >>> From: Keith Marshall via MinGW-users <min...@li...> >>> >>> TRT would be to be to have a user defined feature test, (which is >>> what my patch effectively does, although a user defined feature >>> test macro should not be named with double initial underscores). >>> Unfortunately, comments within gmp.h indicate that GNU MP >>> maintainers are opposed to placing any onus on users, to define >>> such a feature test macro, so such a solution would require us to >>> maintain, in perpetuity, a local patch to correct this anomaly for >>> all future GMP releases. I'm reluctant to embark on such a course, >>> but unless the upstream GMP maintainers can be persuaded to see the >>> light, it may become necessary. >>> >>> If we are to adopt any such feature test, I'd prefer it to exist in >>> a MinGW specific namespace, and not specific to GMP, but rather to >>> direct choice between static and dynamic linking for any libraries >>> which offer that choice. Any suggestions for a suitable macro >>> name? > >> I'm lousy with names... __MINGW_SHARED_LIB and __MINGW_STATIC_LIB, >> perhaps? Or maybe a single macro __MINGW_BUILDING_DLL, whose value >> is either 1 or 0? > > Well, it's a feature test macro which should be user defined; naming > it with two initial underscores really isn't appropriate. It should > either have none at all, or adopt the POSIX.1 convention of one such > underscore, (which would be consistent with our usage elsewhere). > > FWIW, I wasn't demanding that you, Eli, provide a name; I was rather > inviting suggestions from the MinGW User community at large. My own > thinking runs like this: > > - The crux of the issue is that GMP, and by extension MPFR, insist > on decorating function prototypes with __declspec(__dllimport__), > via gmp.h, when libgmp-10.dll is built (--enable-shared). This > may be appropriate for other Windows compilers, but it is wrong > for GCC -- in fact, it precludes any libgmp.a vs. libgmp.dll.a > choice, as directed by GCC's -static flag, (or ld's -B static). > > - Whereas GMP decorates prototypes with __GMP_DECLSPEC, (which is > always defined as __declspec(__dllimport__) for GMP client code, > when GMP is built with --enable-shared), MinGW decorates them > with _CRTIMP, which is defined in _mingw.h as nothing, (unless > the implementation private macro __USE_CRTIMP is defined, which > is never the case, except in our fesetenv.c, or if end-user code > subverts its intended privacy); thus, MinGW prototypes are almost > *never* decorated with __declspec(__dllimport__). > > Thus, I propose a new user definable _MINGW_CRTIMP_DECLSPEC macro, to > be interpreted by _mingw.h, such that if defined, __USE_CRTIMP will be > defined as 1, otherwise as 0; then we could add conditional code for > both GMP and MPFR, to honour __USE_CRTIMP when __MINGW32__ is defined > by GCC itself. > > Supporting something like _MINGW_CRTIMP_DECLSPEC could be useful in its > own right -- i.e. it would give _CRTIMP useful meaning -- my biggest issue with all of this is that developing related patches for GMP and > MPFR, and getting them accepted upstream, could prove more difficult, > and ultimately more time consuming, than just adopting the build method > I've already outlined. Is there a complication when these libraries are embedded in the GCC source directory tree and built as part of GCC? So trying to circumvent the madness becomes a bit ludicrous. -- Earnie |
From: Keith M. <kei...@us...> - 2018-01-18 22:19:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/01/18 19:17, Eli Zaretskii wrote: >> Date: Thu, 18 Jan 2018 16:18:36 +0000 >> From: Keith Marshall via MinGW-users <min...@li...> >> >> TRT would be to be to have a user defined feature test, (which is >> what my patch effectively does, although a user defined feature >> test macro should not be named with double initial underscores). >> Unfortunately, comments within gmp.h indicate that GNU MP >> maintainers are opposed to placing any onus on users, to define >> such a feature test macro, so such a solution would require us to >> maintain, in perpetuity, a local patch to correct this anomaly for >> all future GMP releases. I'm reluctant to embark on such a course, >> but unless the upstream GMP maintainers can be persuaded to see the >> light, it may become necessary. >> >> If we are to adopt any such feature test, I'd prefer it to exist in >> a MinGW specific namespace, and not specific to GMP, but rather to >> direct choice between static and dynamic linking for any libraries >> which offer that choice. Any suggestions for a suitable macro >> name? > > I'm lousy with names... __MINGW_SHARED_LIB and __MINGW_STATIC_LIB, > perhaps? Or maybe a single macro __MINGW_BUILDING_DLL, whose value > is either 1 or 0? Well, it's a feature test macro which should be user defined; naming it with two initial underscores really isn't appropriate. It should either have none at all, or adopt the POSIX.1 convention of one such underscore, (which would be consistent with our usage elsewhere). FWIW, I wasn't demanding that you, Eli, provide a name; I was rather inviting suggestions from the MinGW User community at large. My own thinking runs like this: - - The crux of the issue is that GMP, and by extension MPFR, insist on decorating function prototypes with __declspec(__dllimport__), via gmp.h, when libgmp-10.dll is built (--enable-shared). This may be appropriate for other Windows compilers, but it is wrong for GCC -- in fact, it precludes any libgmp.a vs. libgmp.dll.a choice, as directed by GCC's -static flag, (or ld's -B static). - - Whereas GMP decorates prototypes with __GMP_DECLSPEC, (which is always defined as __declspec(__dllimport__) for GMP client code, when GMP is built with --enable-shared), MinGW decorates them with _CRTIMP, which is defined in _mingw.h as nothing, (unless the implementation private macro __USE_CRTIMP is defined, which is never the case, except in our fesetenv.c, or if end-user code subverts its intended privacy); thus, MinGW prototypes are almost *never* decorated with __declspec(__dllimport__). Thus, I propose a new user definable _MINGW_CRTIMP_DECLSPEC macro, to be interpreted by _mingw.h, such that if defined, __USE_CRTIMP will be defined as 1, otherwise as 0; then we could add conditional code for both GMP and MPFR, to honour __USE_CRTIMP when __MINGW32__ is defined by GCC itself. Supporting something like _MINGW_CRTIMP_DECLSPEC could be useful in its own right -- i.e. it would give _CRTIMP useful meaning -- my biggest issue with all of this is that developing related patches for GMP and MPFR, and getting them accepted upstream, could prove more difficult, and ultimately more time consuming, than just adopting the build method I've already outlined. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJaYR2QAAoJEMCtNsY0flo/qUMP+wfayJ1WQP91/WoRNQqUsggf /w8haIcy2SELXE5925nOrFk+oDTbgZtqy++ujrsmis25WXSumUutUCKMTMhC/abE XQpS9CuIqTRudeWxae+A/vxhmQK+DEtaiUnkEIeQ6bT13yCb1sww2yYPcv1B1PXW qfFtJNNBU1iMPG8Jm08KWzxwTdCbvMr166bHRwzbyXSHhqwMwUcSHR2nrxMC8fj8 wbFrVqxcKjqiTWKe1WmJwY3zW4vDwwgEf9rqNJaVl9SGmZQR4WQ6Xp74Cf4tqOws oUpTtKZ7mrMPgxPTYKOhswOwnIfhWv4vkKYHkRbsrDQtgYrFfczP521XCGOGYB3Q 7eXVy97kZzM/Z7wyah39xWQ8/Q/SfozsHiNeq5ubEkXuiZPep2vwr5wuZku8r9GV AuyPL6DOcOnK35G3Hm98c/qyYvzuwribdRvIsD8Jn9BnsIcmUf6eVMAqEgX0hCzQ P2Qigh+F8Io0JealzA4FrlDzNd4wI6VZMEU6gScDlu2LFtFl8yLqpJgByF66bCfn C7vqlsRGuqSVnT/p6pgYfvrVPXXBe9OqqVuHCgsz4oIM5N3SCzZlt9orylXrG1UC G2O8CkdHq+N0WtCeZkdkvHIOJ6j9dXyudMYCOVCKMr75fCQ8Eqc3POR74cijBQYm wNjD+Eetl2AQAkLVFufc =VEZh -----END PGP SIGNATURE----- |
From: Eli Z. <el...@gn...> - 2018-01-18 19:18:06
|
> Date: Thu, 18 Jan 2018 16:18:36 +0000 > From: Keith Marshall via MinGW-users <min...@li...> > Cc: Keith Marshall <kei...@us...> > > TRT would be to be to have a user defined feature test, (which is what > my patch effectively does, although a user defined feature test macro should not be named with double initial underscores). Unfortunately, > comments within gmp.h indicate that GNU MP maintainers are opposed to > placing any onus on users, to define such a feature test macro, so such > a solution would require us to maintain, in perpetuity, a local patch > to correct this anomaly for all future GMP releases. I'm reluctant to > embark on such a course, but unless the upstream GMP maintainers can be > persuaded to see the light, it may become necessary. > > If we are to adopt any such feature test, I'd prefer it to exist in a > MinGW specific namespace, and not specific to GMP, but rather to direct > choice between static and dynamic linking for any libraries which offer > that choice. Any suggestions for a suitable macro name? I'm lousy with names... __MINGW_SHARED_LIB and __MINGW_STATIC_LIB, perhaps? Or maybe a single macro __MINGW_BUILDING_DLL, whose value is either 1 or 0? |
From: Keith M. <kei...@us...> - 2018-01-18 16:18:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/01/18 14:56, Eli Zaretskii wrote: >> FWIW, I built this as follows:-- > > It is strange that such complications are needed in this case. I > guess the root cause is gmp.h? Yes. GMP itself insists that it be built with either: --enable-static --disable-shared or: --enable-shared --disable-static No other combination is permitted; nor apparently, is omission of any one option, or both, within either pairing. In the first case, the installed gmp.h is generated with hard-coded: #define __GMP_LIBGMP_DLL 0 while in the second, this becomes: #define __GMP_LIBGMP_DLL 1 > If so, perhaps it would make sense to release a version of GMP that > doesn't have this problem in that header? TRT would be to be to have a user defined feature test, (which is what my patch effectively does, although a user defined feature test macro should not be named with double initial underscores). Unfortunately, comments within gmp.h indicate that GNU MP maintainers are opposed to placing any onus on users, to define such a feature test macro, so such a solution would require us to maintain, in perpetuity, a local patch to correct this anomaly for all future GMP releases. I'm reluctant to embark on such a course, but unless the upstream GMP maintainers can be persuaded to see the light, it may become necessary. If we are to adopt any such feature test, I'd prefer it to exist in a MinGW specific namespace, and not specific to GMP, but rather to direct choice between static and dynamic linking for any libraries which offer that choice. Any suggestions for a suitable macro name? - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJaYMjcAAoJEMCtNsY0flo/aHAP/jqxFuq/wHgUkRqd2O2O3qrN ykG5glQj3whLWxb6q71WbpOxqG7fr/g3HYV0KIQGzIGP604vnk11t0xHn4crLH9z fTXGpqLCgEdOMSDbAOqPtWwt4d+SrBbMyNzCiivIP6NCZMio3qUwyW4iuvAmIGpy dOCXHj4PJ+JS+elXcexNUBOC247T/q9ymqIAGzfxJdAknG5CADw1sKL3zTzf/m66 LNglkUoFAkX83oEuH6Bz+0Obv56JsyiI3Fe3eAzlDI3QLZJIK5YPmXNNfUDYxmZZ 8IsUZgfXN41HjKw9Xy7ob+IHHbtoBVALSz8VcD9uW2FqNQuw8oedwnPoZjXsvHWb HksuyRZNVuVf7Rmmt0No4BQYsZaEomxj/PrWy6nFaL6CwhN7zAbBDPFdHKT0U5wP EwmMHbqvxznl8eHgDjbwOLEP57yWuNZZbzApDgwUs/tO0UwnUG6ukAdSgCgQlsLT QTu+3WURkF+dmNRCJKfS61ORNchLXivMLMmD1gwGvyx5/GucuMYhsIkH9Bp53rxK dt6U3HzfN7F3nsr40uYi72iiMdZulBlNklPNqMQsyXcglGbaJF6PisEyw5sNyCQt kiuqVZ3uif11PLKSLhM5v62rfUaHB8CC3AEGF2k0QtlFHB7pIunDVUddMYt5IbqH YRbMcdZahYPVWZ447FKd =5kiC -----END PGP SIGNATURE----- |
From: Eli Z. <el...@gn...> - 2018-01-18 14:57:10
|
> Date: Thu, 18 Jan 2018 09:49:43 +0000 > From: Keith Marshall via MinGW-users <min...@li...> > Cc: Keith Marshall <kei...@us...> > > On 17/01/18 16:05, Eli Zaretskii wrote: > > Thanks in advance. I confirmed that I see the same problem in libmpfr > > 3.1.5 I've built locally at some point. > > So, I guess you did the same as I: build with neither --enable-static > nor --enable-shared, and an --enable-shared variant of include/gmp.h According to config.log I have here, yes (this was more than a year ago, so I have long forgotten what I did, exactly). > Does the mpfr-3.1.5-2 build, now published on our SourceForge FRS, > resolve the issue? I will have to try to build GDB again to see that in action, but on first sight it looks like the issue is indeed resolved: the only "_imp_*" symbols in libmpfr.a are those from msvcrt.dll. Thanks! > FWIW, I built this as follows:-- It is strange that such complications are needed in this case. I guess the root cause is gmp.h? If so, perhaps it would make sense to release a version of GMP that doesn't have this problem in that header? |
From: Keith M. <kei...@us...> - 2018-01-18 10:45:00
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oops! On 18/01/18 09:49, Keith Marshall via MinGW-users wrote: > 4. Create a complementary shared-only MPFR build: > > $ mkdir ../mpfr-3.1.5-shared && cd ../mpfr-3.1.5-shared > $ mingw-pkg --srcdir=../mpfr-3.1.5 --option='configure > CPPFLAGS=-D__GMP_LIBGMP_DLL --enable-static > --disable-shared' configure > ... > $ make > ... > $ mingw-pkg --keep-staged-image dist > ... Obviously, this is a copy-and-paste oversight; the configure step should, of course, read: $ mingw-pkg --srcdir=../mpfr-3.1.5 --option='configure CPPFLAGS=-D__GMP_LIBGMP_DLL --enable-shared --disable-static' configure ... - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJaYHqtAAoJEMCtNsY0flo/vNAP/19yYowrVV4/atVFEyXWkVua nI+jFgx6hHQEdE/tO9qHv92PnE8SbxwEkJV9q1FH5Q3j8fBBweelZbuBVX21/KRH FADz0k7xOPtnI5vE8UqYKTH+nzsRBPDs/h6Oww26NgwLZtwTbNHl9Q9qb48Onq19 N80RFz79lZruDgQWH/itS3OTE1CVQCH2pGDlUpf8afTvQqF3+qH+aD3pPVImppbD u5ZRcvcur6W+QfBZxJ1kYyE59jOEj5HiYbAElyWGpZRV7ffNWssY1mJUVsVkwqjU iTpvJioJBZDEtxuSOH4xBbnEuq18dr+hLnDDpykRiqXCg/1UkDC++6USD5z5kjgD onWYx/gI+bAKzCv0f4rJU83iR25Be5x2bnUI3UElzsWhI53dz2+hv35u2hqw1H0r gByrr9vu9VcGprvG4cRRRQCYme3ozJY3nDrpIplv4+vcvMojLNsZac9+cfo0d04g unc1ZWgWyPWwzxo7C9mrhMuDkCqWUol8hc6VWrANLx96Pg9rM6WoCbxNL7KavOU3 lXiP1kHf0oWiwsRfwCejLi1CXbJJiU7gLU8cdhrKnODsEfW0BwCulmHfcyUAAuDN N8db6RmgO3LJcwkDzfYckeZYHhinoWBQmzO8nrvzdbG3mE7FGmFZ4oBJsSoUVJiO zcpzQp58cqsPPwx8F9+W =Au9k -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2018-01-18 09:49:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/01/18 16:05, Eli Zaretskii wrote: > Thanks in advance. I confirmed that I see the same problem in libmpfr > 3.1.5 I've built locally at some point. So, I guess you did the same as I: build with neither --enable-static nor --enable-shared, and an --enable-shared variant of include/gmp.h Does the mpfr-3.1.5-2 build, now published on our SourceForge FRS, resolve the issue? FWIW, I built this as follows:-- 1. Patch the *installed* --enable-static version of include/gmp.h, per attached. 2. In my mpfr-3.1.5/arch/mingw32/mpfr-3.1.5-mingw32.pkgspec, (a local addition to the otherwise unmodified upstream source), bump the pkgrelease number from 1 to 2. 3. Create a static-only MPFR build: $ mkdir mpfr-3.1.5-static && cd mpfr-3.1.5-static $ mingw-pkg --srcdir=../mpfr-3.1.5 --option='configure --enable-static --disable-shared' configure ... $ make ... $ mingw-pkg --keep-staged-image dist ... 4. Create a complementary shared-only MPFR build: $ mkdir ../mpfr-3.1.5-shared && cd ../mpfr-3.1.5-shared $ mingw-pkg --srcdir=../mpfr-3.1.5 --option='configure CPPFLAGS=-D__GMP_LIBGMP_DLL --enable-static --disable-shared' configure ... $ make ... $ mingw-pkg --keep-staged-image dist ... 5. Merge static libmpfr.a into shared distribution image: $ ln ../mpfr-3.1.5-shared/dist/staged/libmpfr.a dist/staged/lib $ mingw-pkg --pre-stage --keep-staged-image dist sign ... BTW, in pursuing this issue, I discovered a logic error in my working copy of include/_mingw.h, (not in mingwrt-5.0.2), so thanks for giving me this exercise, which allowed me to fix the bug before it crept into mingwrt-5.1 - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJaYG22AAoJEMCtNsY0flo/FFgP+wd8FHcnNQ8ck0NfGRdjiVAx gwSKwza4Sc2PJFqZu7RVjw61BNMtIaZFzNklhsUALU9HDyFIbSE4XevDCwLPkYCK C2z4V+ociZy+QdtQhrYQKPUnIzxcrtp/HQVWRcqGNRlL7vDjoGgo0oTYnBIcN5xo yNtJq41VCTkKg9Bek3ZLU17WX+be1sAuT0yQjljvih4nFmbmeG/UeG0bMs74ZDm/ +UsTO8DbJM7UNDYfl/l/tJPdT7lV/LUpr66MHxUmda3DEILkGTNrwMnWKfKI7T7Y wJKSvksu9WdF4p0RKtPH082VYD+/4/5Bht9Wpalp7pV/0y70gukD8RAbgqYziY1P j1NT2vcSl4G/FcMnmT9WJMI2TZ2TjqyY/hNVspl9xqhIUPXKlZWuGE8dYNwnfBTy 1fOXbE4eOZRNc8HFBFZfGEfs5rGxvgdd1qpHMgCuoHOuMtFXJhaWV06jHXUs1qZ9 DoZlKmzTnYyWS0BGUlUIx9RHbe4m0SucusBY1TEGCKe3NhdI+FRi+Ewd6Lzb/G4K 0NqM6a0kzchBfth02aoNYl2jezpk0dzx6+tvMuSWbjZYZiB/wbo34yObejVvi8Bo iY1OKXZJ6f0xcHAsfg0RAH/Y7mBkjt45M3t2VOLXeR19ngxX38OR59jEgBdkeXgt U4tOPM9K2zvf4kV0kQS4 =EL7q -----END PGP SIGNATURE----- |
From: Eli Z. <el...@gn...> - 2018-01-17 16:05:36
|
> Date: Wed, 17 Jan 2018 15:18:32 +0000 > From: Keith Marshall via MinGW-users <min...@li...> > Cc: Keith Marshall <kei...@us...> > > If I do specify --enable-static for the MPFR build, then I *must* also > specify --disable-shared, (or vice-versa), and the build *will* then > fail if GMP was not built with identically the same combination of > this pair of options. With '--enable-static --disable-shared' I will > get a static libmpfr.a which also depends on static libgmp.a; obviously, > this makes it more complicated to create a hybrid distribution, which > will properly support GCC ld's libmpfr.a vs. libmpfr.dll.a selection. > > I can (and will) do this, but it may take a day or two to work out > the complexities. Thanks in advance. I confirmed that I see the same problem in libmpfr 3.1.5 I've built locally at some point. |
From: Keith M. <kei...@us...> - 2018-01-17 15:24:08
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/01/18 15:00, Earnie via MinGW-users wrote: > Or perhaps an issue with the version of libtool used. Libtool uses its > own assumptions for building libraries and those assumptions have been > wrong for Windows and MinGW in the past including ignoring command line > options. Nope. It is the GMP and MPFR build systems' inability to properly support hybrid builds, which are compatible with GCC ld's static vs. dynamic link mechanism. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJaX2qTAAoJEMCtNsY0flo/2rYP/2X/x9cOo6uv26UHhSmNpLjU uDyQPvzRY05hoMNruoxYzjYvBPW8zEkVZVZAnJiHF/+aHFYs68AoQNvLuea2X+jS D46H8BUdwLZue5gJR9xxxV4jE+uyBNsBM7A7K4BaZfICD2J0HI9QU6P7CgLIKSwD rkx5jrS4Zw2abkyxirLst2H3hv0J2L+X2xNxxZ1DJuOafwiqUtBv5bqx1ZarI1/e 3MTHlqwQg9zkUpc/mBIcTfFK+Lh8d+Dj7b02EEJ7C3VnUpy2LDY3k7YqjpSnNQb/ FCbHN4LBhm85o9WuKiVFib2TmJS2AzW/4nEKx+BvFPVtCVYErYIvx3XwJoPy7ci5 pCaUWDtX5F7y7hTSCHrz6pO+bXwUgS40+rjiBxME8hsqTxR8g1NN2gwjjdno09hw B9SEkUDIVZ73SnE+ojKMhVoyDPuC5Z3raHH20Il+ZRnaJ6fyQnB2nVvbQUeZ0Fzy DGjfJAgfnhN7iMxZCEd0qZE/h3Fym6foJ8Wbip50JFBID07+XzhBdiyaAVs0S/PP ytAhY2RyRvn9YKHNSODjnSticzw+8UwF87BlFyn1mkJnUXHL0WDUey4JRYFEs37U i4P9+xKZTjBkGPvQX2LopUkoi6l/ku3dpxRjaULDLYEBm0z6kdKS9hwXPQcXOcNI b7YeENdSsTAmJRl994iD =EGeU -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2018-01-17 15:18:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/01/18 20:04, Keith Marshall via MinGW-users wrote: > Perhaps this is a bug in the MPFR build methodology, when building as a > static library with both --enable-static and --enable-dynamic? Or maybe > a consequence of a bad design decision (IMO) by the GMP developers; they > provide disparate (and incompatible) versions of include/gmp.h for each > of the two configurations? Okay, I've done some follow-up investigation, which suggests that the problem arises from a combination of both of these. > (FWIW, the gmp.h which we have distributed is from the > '--enable-static --disable-shared' build). However, my MPFR build was against the gmp.h from a --enable-shared - --disable-static build of GMP, and with *neither* of these options for the MPFR build itself. It turns out that this configuration is allowed, and will create both static and dynamic MPFR libs, but with *both* of them requiring the DLL version of libgmp. If I do specify --enable-static for the MPFR build, then I *must* also specify --disable-shared, (or vice-versa), and the build *will* then fail if GMP was not built with identically the same combination of this pair of options. With '--enable-static --disable-shared' I will get a static libmpfr.a which also depends on static libgmp.a; obviously, this makes it more complicated to create a hybrid distribution, which will properly support GCC ld's libmpfr.a vs. libmpfr.dll.a selection. I can (and will) do this, but it may take a day or two to work out the complexities. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJaX2lIAAoJEMCtNsY0flo/URAQAIz5q8XKb9ZMSsjb5o6ts1hg nXdf3tob3CY0jaLb73uT2KCC/KoZvbbjYba73yeZYrbRbDzPVNifD3b/A83OKAm5 JfbeT3hhaxnsmEAFPood/N5F417N9wsTQhibo9Zr8uXFpVcyP0pvO3UMMT7M0fev 3F/0YX1q+VPHrMlYKmjClsk80xmSF/bqZeIeu0S93pCLmbR5dQOOU9Cv2FZqHH2S dIiIbJs84NQGOeeuMwJEQX92C2jTX0Ixpe4M4fi+ch1OoFc4TL936pcruycIdxiC Xk/TsTQmHVkZCRGMKN4K7qw3c9l/1Y3G7lo5XCJ9Ewzyg3kXGd7sqlY0KGbeMzCB +N7ePWDXp4hpL23V2RjGkoTsZczbvhyNWkQEpnJ6QHc25cLPFIOKxOx8gr9YxIK3 +gl0ZZNjNYUv9y6X5Ag0FsUOFuESlwgQgq/DrVB/k70sbVTOjxG4bf/f+UrJGobG Bdb8Ua4OxsZJNNAM+Vq9vu46I3GcXHY1LSCwVpC7GuZMmwMK50mpKmTep2745K3K S44SpmNthJNbe/rcIVhbs563dYU2Q7WnSJEW1tmiP3uL97FS0UoKLXivAdn2nulc rBAbZA4+bYCagcX9yXqrL+oqB5XzPLlJmw2N4AycSUpSN4t0sVqQnHWU32/YtdaI vef6PKjUYHBzdZengnI9 =qSnX -----END PGP SIGNATURE----- |
From: Earnie <ea...@us...> - 2018-01-17 15:01:09
|
On 1/16/2018 3:04 PM, Keith Marshall via MinGW-users wrote: > On 16/01/18 17:41, Eli Zaretskii wrote: >> It turns out libmpfr.a includes numerous references to such import >> symbols, which sounds like it was produced with GMP in the form of a >> shared library? How is that possible, and why was that done? It >> means this libmpfr.a cannot be used for static linking, AFAIU. > >> Or am I missing something? > > I don't think so; I'm seeing the same proliferation of dynamic linking > symbols. I guess I've never noticed the issue, because I normally use > dynamic linking for these GCC prerequisite libraries. > > FWIW, I built all of these libraries from unmodified upstream sources, > using their build systems to generate both static and dynamic variants. > Perhaps this is a bug in the MPFR build methodology, when building as a > static library with both --enable-static and --enable-dynamic? Or maybe > a consequence of a bad design decision (IMO) by the GMP developers; they > provide disparate (and incompatible) versions of include/gmp.h for each > of the two configurations? (FWIW, the gmp.h which we have distributed > is from the '--enable-static --disable-shared' build). Or perhaps an issue with the version of libtool used. Libtool uses its own assumptions for building libraries and those assumptions have been wrong for Windows and MinGW in the past including ignoring command line options. -- Earnie |
From: Keith M. <kei...@us...> - 2018-01-16 20:05:08
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/01/18 17:41, Eli Zaretskii wrote: > It turns out libmpfr.a includes numerous references to such import > symbols, which sounds like it was produced with GMP in the form of a > shared library? How is that possible, and why was that done? It > means this libmpfr.a cannot be used for static linking, AFAIU. > > Or am I missing something? I don't think so; I'm seeing the same proliferation of dynamic linking symbols. I guess I've never noticed the issue, because I normally use dynamic linking for these GCC prerequisite libraries. FWIW, I built all of these libraries from unmodified upstream sources, using their build systems to generate both static and dynamic variants. Perhaps this is a bug in the MPFR build methodology, when building as a static library with both --enable-static and --enable-dynamic? Or maybe a consequence of a bad design decision (IMO) by the GMP developers; they provide disparate (and incompatible) versions of include/gmp.h for each of the two configurations? (FWIW, the gmp.h which we have distributed is from the '--enable-static --disable-shared' build). - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJaXlrqAAoJEMCtNsY0flo/20EP/Ri2UbcHRdDL2Tdb7NJna57D 8IZ/f+hMfG+pRDmxcovKd0Is2mND/2ysFKPQCuGKQRx88g3ajoeakUosqUkOyq9Z nQtQzUrf8/EDFqH9E2zbS8neQdAoYb3A9sr8i1VzwY74w0xpJVFBqlvMdCy3QnEy llHyWN4zBkODz0hq4xwSPksQa+/7cUKrRglJsWVDIS/9t9fot6sDF4+ZTp8nkkUr TPk+61iKOWHDuKjerdxw7J4pzeMF/pBoSfvmlcMhCcgIhAUCVPfh9kVj8QNsb/2+ dSAt35O43CfESZSWwR1WqVAPRxF6YLTkahN084oBv8SA28qaazFfraAPCihueGTs KTGJ5VEAjKjDdtCU7mp5e9VGkwvcfR0ByMgvqqsBF3U2y3OBERFP5JI0Q+T1bMAX SRrdkrPYmwhLqQJ8PTi9CN1wq8aemYgMug5pU1Jk6iPROX4Iv9U/kQo47hghqoIP TnyPqdlYrPPsJ6oCDagWwH3Wrt/xNfIBsdgA2LqsjpCKhtPJk2WUh3j4JK0BdR8L 7xXthEwGQy5hBSirGto+TvuF19foY7NyHlm3Bfjmt/cOes1J7gGJN4F0RVooCyEG DnL2nmEgs5B6iXMzL/cpDPSbXog+H5Ta9Sa68uUfYgyu1dR+PkmdA0ud3TO4w70i W/9Q3WHCaWZf8I94kyqm =YSIZ -----END PGP SIGNATURE----- |
From: Eli Z. <el...@gn...> - 2018-01-16 17:41:59
|
I've tried to build the pre-release of GDB 8.1 today, and its configure script failed to detect that I have libmpfr installed. When I looked into that, I saw in config.log that when it tried to link a test program by statically linking it against libmpfr, the linker failed due to an unresolved external named _imp____gmp_get_memory_functions. It turns out libmpfr.a includes numerous references to such import symbols, which sounds like it was produced with GMP in the form of a shared library? How is that possible, and why was that done? It means this libmpfr.a cannot be used for static linking, AFAIU. Or am I missing something? |
From: Eli Z. <el...@gn...> - 2018-01-15 05:53:01
|
> From: Satya Prakash Prasad <sat...@gm...> > Date: Mon, 15 Jan 2018 10:23:24 +0530 > > I have tried many ways to print stacktrace / backtrace in MinGW 64 - but it seems that it is not possible > anyway. > > Seems like backtrace library and its required includes / compiler flags are not available in MinGW - inclusion > of execinfo.h states error and so is compiler flag -rdynamic . > > Please let me know a clean method to generate a backtrace stack of a function - it would better if there is no > external dependency is there but if required we can make use as there is no such other mechanism If you want to print a backtrace with symbols, you need to link against debug libraries. But if you only need addresses, you can do it without those libraries, see how Emacs does that on Windows. These addresses then can be converted to human-readable file names, function names, and line numbers using the addr2line utility that comes with Binutils. In general, for serious backtrace capabilities, you will need a debugger, such as GDB. |
From: Satya P. P. <sat...@gm...> - 2018-01-15 04:53:31
|
I have tried many ways to print stacktrace / backtrace in MinGW 64 - but it seems that it is not possible anyway. Seems like backtrace library and its required includes / compiler flags are not available in MinGW - inclusion of execinfo.h states error and so is compiler flag -rdynamic . Please let me know a clean method to generate a backtrace stack of a function - it would better if there is no external dependency is there but if required we can make use as there is no such other mechanism |
From: Keith M. <kei...@us...> - 2018-01-08 18:59:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/01/18 16:18, Peter Bohning wrote: > He does it again! After you call me down and threaten to ban me for > finally replying to the guy? I guess it's just because he's writing > me off-list to get my goat? Is that it? > > Why don't you ban him? Ban him from what? As you say, he's writing to you off-list; not one of his replies has been directed to the list, (other than you copying them here). The two of you are welcome to trade insults all you like, off-list, but I don't want to see any more of them here. I can't ban your private (off-list) dialogues, but you don't need to air your dirty linen in public. - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJaU7+WAAoJEMCtNsY0flo/pjkP/je44duPVmmJ9ulNhVS4QC/8 PCE+Guk7A9Hv0VBW86Ffra7L+c9kJpHkdw+JEtzhAQxSYjXmZfvYaJzXmZTuFvWJ wgZvS+v00/jv0X+JWPHne4iZTMQjpx59A159z+F2/pwZObexuzQ7Vkh/ZAWuslMy 0ZXKeL58i65GYxz86Kfo364dziMzYnfIL1tPAmdIyd5mD4OyWDcupBd8TeVDlk9B O84bW1TcFb5szH94u6hfCrJyDx8tSmVlkwRgNHO17fTdgXC+jE4KvRp8SAsHYLm3 mEH706ptmjanrvQuLnJNZb3WKPjq3seh90OajwxZa9CPYqE/2AOOycEKLRcR1vIG +i86MikOh/oNsRjHw3N4LEy5wd3dWhn7ihU5k6pJY3qBICxy/P37r12A8DzWmjlS ck4eK2in6vfJG0zcj1EDyRrs5rJjXRC9pXXAqC3NVPVxgFhBMAOt8R0zPFL5zt8z A5i4a+mZw4hR2q3/EYM45eo3zk3V8ET6xqNdm3xMn+7Hgaq9X+4V0tEnAq5zS/w7 zhaKCiRc1zNNyXRuqje+JkJ6jsfSZYBePTOCUPfdOglQ3Ym7xbPkmdwDu8ghHpWB dlRJ+bwmxgoiI8KlqxEMHbcDYxLwygaqr23XVeV5O0KaIvuLNSHiMHw8o/9s3O2A SRlXkpD/DmRWxxPcYysU =W8Ak -----END PGP SIGNATURE----- |