From: Chris S. <ir0...@gm...> - 2008-10-31 03:09:45
|
Now that binutils-2.19 is official, I'm working on creating a new release for MinGW. I'm assuming that now this is an 'official' release, I can mark this as current (replacing 2.17.50)? Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Chris S. <ir0...@gm...> - 2008-11-30 21:46:52
|
I assume I'm safe to move binutils-2.19 to current? As suggested, I've given it 4 weeks and have yet to see an issues on the mailing list about it. Chris -- Chris Sutcliffe http://emergedesktop.org |
From: John E. / T. <td...@td...> - 2008-11-30 23:30:46
|
Chris Sutcliffe wrote: > I assume I'm safe to move binutils-2.19 to current? As suggested, > I've given it 4 weeks and have yet to see an issues on the mailing > list about it. > It gets my vote; I've been using it since the announcement without any problems whatsoever. -John E. |
From: Keith M. <kei...@us...> - 2008-12-01 22:54:45
|
On Sunday 30 November 2008 23:30:32 John E. / TDM wrote: > Chris Sutcliffe wrote: > > I assume I'm safe to move binutils-2.19 to current? As > > suggested, I've given it 4 weeks and have yet to see an issues on > > the mailing list about it. > > It gets my vote; I've been using it since the announcement without > any problems whatsoever. So, it clearly works fine, when built natively. However, I have been unable to get it to build cross-hosted; first, there appears to be a rogue dependency, which invalidates the bfd.info file during the secondary configure step. On working around that, by touching the affected file, and running make again, I get a multiple definition of `main', and a bunch of unresolved references when linking ld-new: $ ../binutils-2.19 --prefix=$HOME/mingw32 --target=mingw32 \ --with-gcc --with-gnu-as --with-gnu-ld --disable-nls --disable-debug : $ make CFLAGS='-O2 -fno-exceptions' LDFLAGS=-s Initially fails, with no indication as to why; immediately running the same `make' again, reveals the `*.info' problem, requiring `makeinfo' which I don't have installed, and don't want. Touching the `*.info' files already present in the source tree, and running `make' again, gets me to: libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -fno-exceptions -s -o ld-new ldgram.o ldlex.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o ei386pe.o deffilep.o pe-dll.o ../bfd/.libs/libbfd.a ../libiberty/libiberty.a -lz deffilep.o: In function `main': deffilep.c:(.text+0x0): multiple definition of `main' ldmain.o:ldmain.c:(.text+0x12e0): first defined here ei386pe.o: In function `gld_i386pe_unrecognized_file': ei386pe.c:(.text+0x631): undefined reference to `def_file_parse' pe-dll.o: In function `pe_implied_import_dll': pe-dll.c:(.text+0x121c): undefined reference to `def_get_module' pe-dll.c:(.text+0x1390): undefined reference to `def_file_add_import' pe-dll.c:(.text+0x1456): undefined reference to `def_file_empty' pe-dll.o: In function `pe_dll_build_sections': pe-dll.c:(.text+0x420f): undefined reference to `def_file_add_directive' pe-dll.c:(.text+0x439a): undefined reference to `def_file_add_export' pe-dll.c:(.text+0x4a08): undefined reference to `def_file_add_export' pe-dll.c:(.text+0x4caa): undefined reference to `def_file_empty' collect2: ld returned 1 exit status Very disappointing, since 2.18.50 builds OOTB, with exactly the same configuration options. Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2008-12-02 02:14:58
|
> So, it clearly works fine, when built natively. However, I have been > unable to get it to build cross-hosted; first, there appears to be a > rogue dependency, which invalidates the bfd.info file during the > secondary configure step. On working around that, by touching the > affected file, and running make again, I get a multiple definition of > `main', and a bunch of unresolved references when linking ld-new: <snip> > Very disappointing, since 2.18.50 builds OOTB, with exactly the same > configuration options. Given that the native build works, are we good, or do we need to hold-off while the cross-compiler is sorted out? Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Hin-Tak L. <hin...@ya...> - 2008-12-02 03:42:04
|
--- On Tue, 2/12/08, Chris Sutcliffe <ir0...@gm...> wrote: <snipped> > > Very disappointing, since 2.18.50 builds OOTB, with > exactly the same > > configuration options. > > Given that the native build works, are we good, or do we > need to > hold-off while the cross-compiler is sorted out? Hiya, which way are you doing the building the cross-compiler? I posted a diff - filed as one of the bugs/features in the sourceforge web site - to update the cross-compile script to cope with the "mingwrt" new naming schemes a while ago, and that seems to work. (I am building on x86_64 linux to host on x86_64 linux to target win32 - I think that's the way to word it). So I have it finished building - I haven't tried building win32 things with it yet. Hin-Tak |
From: Keith M. <kei...@us...> - 2008-12-02 23:07:25
|
On Tuesday 02 December 2008 03:41:56 Hin-Tak Leung wrote: > --- On Tue, 2/12/08, Chris Sutcliffe <ir0...@gm...> wrote: > <snipped> > > > > Very disappointing, since 2.18.50 builds OOTB, with > > > exactly the same configuration options. > > > > Given that the native build works, are we good, or do we > > need to hold-off while the cross-compiler is sorted out? > > Hiya, which way are you doing the building the cross-compiler? At this point, I'm just trying to build binutils-2.19 free-standing, configured for --target=mingw32, with identically the same options as we use in the cross-compiler build scripts. > I posted a diff - filed as one of the bugs/features in the > sourceforge web site - to update the cross-compile script to cope > with the "mingwrt" new naming schemes a while ago, and that seems > to work. I know you did; I've been following up on that, thanks. This problem is not, in any way, related to mingwrt naming. > (I am building on x86_64 linux to host on x86_64 linux to target > win32 - I think that's the way to word it). Yes, that seems right. > So I have it finished building Yes, so have I, with binutils-2.18.50, gcc-3.4.5, mingwrt-3.15.1 and w32api-3.12; it's when I plugged in binutils-2.19 that it broke, and I now know why; the tarball, as shipped by the binutils folks, has: * a messed up timestamp for bfd.info, which depends on elf.texi, and which in turn depends on elf.c; elf.c is newer than either of the dependents, requiring a regeneration of the info file, so building fails if makeinfo isn't installed, even though it isn't supposed to be needed. The regenerated elf.texi is, byte for byte, identical to the distributed version, so the regeneration isn't really necessary; this problem may be resolved by touching elf.texi and bfd.nfo in the source tree, to reschedule the timestamps. * missing deffilep.c, from the ld directory. This can be generated, if bison is installed, but once again, this is not supposed to be necessary, for building from a release tarball; it may be corrected, by adding the generated deffilep.c to the source hierarchy, and repackaging the tarball. > - I haven't tried building win32 things with it yet. No, I haven't got that far yet, either. Chris, lets hold off for a few more days, while I test my repackaged source tarball. When I'm satisfied, I'll upload it to `incoming' for you, then you can go ahead with the release. Regards, Keith. |
From: Hin-Tak L. <hin...@ya...> - 2008-12-02 23:24:31
|
--- On Tue, 2/12/08, Keith Marshall <kei...@us...> wrote: <snipped> > * a messed up timestamp for bfd.info, which depends on > elf.texi, and > which in turn depends on elf.c; elf.c is newer than either > of the > dependents, requiring a regeneration of the info file, so > building > fails if makeinfo isn't installed, even though it > isn't supposed to > be needed. <snipped> > * missing deffilep.c, from the ld directory. This can be > generated, if bison... <snipped> Okay, so the problem you encountered is with timestamps and optional devel tools to regenerate files. My usual work dev box is quite well-equiped in terms of devel tools, so I wouldn't encounter or notice these kinds of problems. (I reckon disk space is relatively cheap and it is just not worth the hassle of digging for CDs or install on-the-fly for rarely used tools, so I rarely take any tool off once I have them installed; basically just keep them around). |
From: Keith M. <kei...@us...> - 2008-12-03 22:28:07
|
On Tuesday 02 December 2008 23:24:24 Hin-Tak Leung wrote: > Okay, so the problem you encountered is with timestamps and > optional devel tools to regenerate files. Yes. > My usual work dev box is quite well-equiped in terms of devel > tools, so I wouldn't encounter or notice these kinds of problems. No, you wouldn't, but that doesn't make it ok to release packages with this sort of defect; in fact, I consider it rather sloppy engineering to fail to check for them prior to publication. > (I reckon disk space is relatively cheap and it is just not worth > the hassle of digging for CDs or install on-the-fly for rarely used > tools, so I rarely take any tool off once I have them installed; > basically just keep them around). Well, I just grab them from the Ubuntu online repositories, when I need them. I don't have GNU texinfo installed, basically because it is incompatible with Ubuntu's info system, and causes severe problems in the synaptic/apt package management domain. Bison was missing because I don't use it myself, and hadn't reinstalled it after my hard disk crashed a couple of months ago. In any case, release tarballs aren't supposed to require any of flex, bison or makeinfo for building on an end user's machine, so quality assurance mandates verifying the build on a machine without them, before distribution. (Something which the binutils folks seem to be notoriously lax about, the more so when `make dist' *doesn't* work as the GNU Coding Standards demand, and they seem to lack any assurance that all required files are actually distributed). Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2008-12-02 23:27:33
|
> Chris, lets hold off for a few more days, while I test my repackaged > source tarball. When I'm satisfied, I'll upload it to `incoming' for > you, then you can go ahead with the release. Fair enough, I look forward to your upload. Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Keith M. <kei...@us...> - 2008-12-08 19:51:14
|
On Tuesday 02 December 2008 23:27:28 Chris Sutcliffe wrote: > > Chris, lets hold off for a few more days, while I test my > > repackaged source tarball. When I'm satisfied, I'll upload it to > > `incoming' for you, then you can go ahead with the release. > > Fair enough, I look forward to your upload. Ok. Turns out to be just two missing files, and one sequence of three files with timestamps out of chronological order. I've filed a bug report on bug...@gn..., last Thursday, but no response yet. Meanwhile, I've prepared an appropriately corrected source tarball, for us to redistribute; before I upload it, we need to agree on the correct name. While `binutils-2.19-mingw32-bin.tar.tz' is correct for the binary release, built for the mingw32 host, it seems to me that to distribute `binutils-2.19-mingw32-src.tar.gz' would not be correct, for this source is in no way specific to the mingw32 host -- it is completely host agnostic! Therefore, I propose[*] any of:-- * binutils-2.19-src.tar.gz * binutils-2.19-generic-src.tar.gz * binutils-2.19-noarch-src.tar.gz On balance, I think I prefer the first, but it isn't by any means an overwhelming preference; what do the rest of you think? Regards, Keith. [*] Rationale: we should ultimately hope to release side-by-side mingw32 and mingw64 builds, derived from a common source; thus a full release might comprise:-- * binutils-2.19-src.tar.gz * binutils-2.19-mingw32-bin.tar.gz * binutils-2.19-mingw64-bin.tar.gz |
From: Earnie B. <ea...@us...> - 2008-12-09 12:21:28
|
Quoting Keith Marshall <kei...@us...>: > On Tuesday 02 December 2008 23:27:28 Chris Sutcliffe wrote: >> > Chris, lets hold off for a few more days, while I test my >> > repackaged source tarball. When I'm satisfied, I'll upload it to >> > `incoming' for you, then you can go ahead with the release. >> >> Fair enough, I look forward to your upload. > > Ok. Turns out to be just two missing files, and one sequence of three > files with timestamps out of chronological order. I've filed a bug > report on bug...@gn..., last Thursday, but no response yet. > > Meanwhile, I've prepared an appropriately corrected source tarball, > for us to redistribute; before I upload it, we need to agree on the > correct name. While `binutils-2.19-mingw32-bin.tar.tz' is correct > for the binary release, built for the mingw32 host, it seems to me > that to distribute `binutils-2.19-mingw32-src.tar.gz' would not be > correct, for this source is in no way specific to the mingw32 host -- > it is completely host agnostic! Therefore, I propose[*] any of:-- > > * binutils-2.19-src.tar.gz > * binutils-2.19-generic-src.tar.gz > * binutils-2.19-noarch-src.tar.gz > I prefer one of the first two. The noarch may confuse the uneducated. > On balance, I think I prefer the first, but it isn't by any means an > overwhelming preference; what do the rest of you think? > > Regards, > Keith. > > [*] Rationale: we should ultimately hope to release side-by-side > mingw32 and mingw64 builds, derived from a common source; thus a full > release might comprise:-- > > * binutils-2.19-src.tar.gz > * binutils-2.19-mingw32-bin.tar.gz > * binutils-2.19-mingw64-bin.tar.gz > What about * binutils-2.19-src.tar.gz * binutils-2.19-mingw-bin32.tar.gz * binutils-2.19-mingw-bin64.tar.gz with a rationale that this gives the correct project name with a host specific binary package name. There is only one MinGW project and there are two binary releases. Earnie |
From: Chris S. <ir0...@gm...> - 2008-12-09 15:03:42
|
>> Meanwhile, I've prepared an appropriately corrected source tarball, >> for us to redistribute; before I upload it, we need to agree on the >> correct name. Given the way FRS works now, in that the files are stored in the user's directory, do you want to update the 'Release Candidate' with your corrected source tarball and rename it to 'Release'? >> While `binutils-2.19-mingw32-bin.tar.tz' is correct >> for the binary release, built for the mingw32 host, it seems to me >> that to distribute `binutils-2.19-mingw32-src.tar.gz' would not be >> correct, for this source is in no way specific to the mingw32 host -- >> it is completely host agnostic! Therefore, I propose[*] any of:-- >> >> * binutils-2.19-src.tar.gz >> * binutils-2.19-generic-src.tar.gz >> * binutils-2.19-noarch-src.tar.gz > > I prefer one of the first two. The noarch may confuse the uneducated. > >> On balance, I think I prefer the first, but it isn't by any means an >> overwhelming preference; what do the rest of you think? I prefer the first as well. >> [*] Rationale: we should ultimately hope to release side-by-side >> mingw32 and mingw64 builds, derived from a common source; thus a full >> release might comprise:-- >> >> * binutils-2.19-src.tar.gz >> * binutils-2.19-mingw32-bin.tar.gz >> * binutils-2.19-mingw64-bin.tar.gz > > What about > > * binutils-2.19-src.tar.gz > * binutils-2.19-mingw-bin32.tar.gz > * binutils-2.19-mingw-bin64.tar.gz > > with a rationale that this gives the correct project name with a host > specific binary package name. There is only one MinGW project and > there are two binary releases. I believe that MinGW32 and MinGW64 are the two official binary targets, are they not? Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Keith M. <kei...@us...> - 2008-12-10 20:32:59
|
On Tuesday 09 December 2008 15:01:57 Chris Sutcliffe wrote: > >> Meanwhile, I've prepared an appropriately corrected source > >> tarball, for us to redistribute; before I upload it, we need to > >> agree on the correct name. > > Given the way FRS works now, in that the files are stored in the > user's directory, do you want to update the 'Release Candidate' > with your corrected source tarball and rename it to 'Release'? That's one option, and probably what I would do; you want the new name to be `Current Release: binutils-2.19'. Then, after you've added the release tarballs, either move the candidates out of the way, into an existing hidden release, or simply delete them. (Moving them keeps them available, although hidden, within the FRS; deleting removes them from the FRS, permanently, although the files remain on SF, and may still be downloaded if the name is known). > >> While `binutils-2.19-mingw32-bin.tar.tz' is correct > >> for the binary release, built for the mingw32 host, it seems to > >> me that to distribute `binutils-2.19-mingw32-src.tar.gz' would > >> not be correct, for this source is in no way specific to the > >> mingw32 host -- it is completely host agnostic! Therefore, I > >> propose[*] any of:-- > >> > >> * binutils-2.19-src.tar.gz > >> * binutils-2.19-generic-src.tar.gz > >> * binutils-2.19-noarch-src.tar.gz > > > > I prefer one of the first two. The noarch may confuse the > > uneducated. > > > >> On balance, I think I prefer the first, but it isn't by any > >> means an overwhelming preference; what do the rest of you think? > > I prefer the first as well. So be it, then; `binutils-2.19-src.tar.gz' it shall be. > >> [*] Rationale: we should ultimately hope to release side-by-side > >> mingw32 and mingw64 builds, derived from a common source; thus a > >> full release might comprise:-- > >> > >> * binutils-2.19-src.tar.gz > >> * binutils-2.19-mingw32-bin.tar.gz > >> * binutils-2.19-mingw64-bin.tar.gz > > > > What about > > > > * binutils-2.19-src.tar.gz > > * binutils-2.19-mingw-bin32.tar.gz > > * binutils-2.19-mingw-bin64.tar.gz > > > > with a rationale that this gives the correct project name with a > > host specific binary package name. There is only one MinGW > > project and there are two binary releases. > > I believe that MinGW32 and MinGW64 are the two official binary > targets, are they not? Quite right. In this context, `mingw32' and `mingw64' are the OSTYPE components of the canonical host designators. We've already agreed that those will appear, as in the forms: * binutils-2.19-mingw32-bin.tar.gz * binutils-2.19-mingw64-bin.tar.gz and I was not inviting further discussion on that. The only case to be discussed, and which we hadn't previously agreed, is that where the tarball isn't specific to only one host, as is the case when we distribute generic sources. Can we now take it as agreed that, for such cases, we will simply omit the host designator? Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2008-12-11 16:19:18
|
>> Given the way FRS works now, in that the files are stored in the >> user's directory, do you want to update the 'Release Candidate' >> with your corrected source tarball and rename it to 'Release'? > > That's one option, and probably what I would do; you want the new name > to be `Current Release: binutils-2.19'. Then, after you've added the > release tarballs, either move the candidates out of the way, into an > existing hidden release, or simply delete them. (Moving them keeps > them available, although hidden, within the FRS; deleting removes > them from the FRS, permanently, although the files remain on SF, and > may still be downloaded if the name is known). I'll upload a new binary tarball with the agreed upon naming convention and I'll rename the release to `Current Release: binutils-2.19'. I'll remove the existing source and release candidate binary tarballs. I'll do this tonight when I get home and I'll send a follow-up email. Once I'm done, Keith, when you have the time, please upload your corrected source tarball. > Quite right. In this context, `mingw32' and `mingw64' are the OSTYPE > components of the canonical host designators. We've already agreed > that those will appear, as in the forms: > > * binutils-2.19-mingw32-bin.tar.gz > * binutils-2.19-mingw64-bin.tar.gz > > and I was not inviting further discussion on that. The only case to > be discussed, and which we hadn't previously agreed, is that where > the tarball isn't specific to only one host, as is the case when we > distribute generic sources. Can we now take it as agreed that, for > such cases, we will simply omit the host designator? I think this is reasonable . Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Chris S. <ir0...@gm...> - 2008-12-12 02:46:03
|
> I'll upload a new binary tarball with the agreed upon naming > convention and I'll rename the release to `Current Release: > binutils-2.19'. I'll remove the existing source and release candidate > binary tarballs. I'll do this tonight when I get home and I'll send a > follow-up email. It's done. I didn't send a notification email or an email to the list because there is no source package. Keith, please upload your source tarball and update the release as your time permits. Thanx! Chris -- Chris Sutcliffe http://emergedesktop.org |
From: mosfet <fo...@sm...> - 2008-12-12 14:47:04
|
On Thu, 11 Dec 2008 21:44:01 -0500, "Chris Sutcliffe" <ir0...@gm...> wrote: >> I'll upload a new binary tarball with the agreed upon naming >> convention and I'll rename the release to `Current Release: >> binutils-2.19'. I'll remove the existing source and release candidate >> binary tarballs. I'll do this tonight when I get home and I'll send a >> follow-up email. > > It's done. I didn't send a notification email or an email to the list > because there is no source package. Keith, please upload your source > tarball and update the release as your time permits. > > Thanx! > > Chris > > Sorry to ask but this corrected version will only be available for mingw or will it be also available from official binutils website ? Is it fixed in binutils trunk ? |
From: Keith M. <kei...@us...> - 2008-12-12 20:19:16
|
On Friday 12 December 2008 14:46:56 mosfet wrote: > > Keith, please upload your source > > tarball and update the release as your time permits. > > Sorry to ask but this corrected version will only be available for > mingw or will it be also available from official binutils website ? Couldn't say; that's up to the binutils folks. You will have to ask on their mailing list. > Is it fixed in binutils trunk ? It was a packaging bug, so it isn't clear what would need to be fixed on binutils trunk -- other than to add support for `make dist' and `make distcheck', which as a GNU project, the binutils folks really should do, but to their shame, and in violation of the GNU Coding Standards, they don't. As I've already said previously, in this thread, I've filed a bug report; you can find it here: http://lists.gnu.org/archive/html/bug-binutils/2008-12/msg00012.html So far, there has been no response. There really isn't any more I can do about this. Regards, Keith. |
From: Keith M. <kei...@us...> - 2008-12-12 19:14:58
|
On Friday 12 December 2008 02:44:01 Chris Sutcliffe wrote: > > I'll upload a new binary tarball with the agreed upon naming > > convention and I'll rename the release to `Current Release: > > binutils-2.19'. I'll remove the existing source and release > > candidate binary tarballs. I'll do this tonight when I get home > > and I'll send a follow-up email. > > It's done. I didn't send a notification email or an email to the > list because there is no source package. Keith, please upload your > source tarball and update the release as your time permits. That's done now, too. I've updated the release notes, to indicate the minimal changes I've made to the original FSF sources, and I asked for a notification mail to be sent to those monitoring the package. May I leave you to handle the press release, and any mail you'd like to send to the list, please Chris? Cheers, Keith. |
From: Chris S. <ir0...@gm...> - 2008-12-13 02:29:27
|
> May I leave you to handle the press release, and any mail you'd like > to send to the list, please Chris? Done, thanx Keith! Chris -- Chris Sutcliffe http://emergedesktop.org |
From: Keith M. <kei...@us...> - 2008-10-31 20:17:15
|
On Friday 31 October 2008 03:09:42 Chris Sutcliffe wrote: > Now that binutils-2.19 is official, I'm working on creating a new > release for MinGW. I'm assuming that now this is an 'official' > release, I can mark this as current (replacing 2.17.50)? I'd be inclined to offer it initially as a `Release Candidate': binutils-2.19-mingw32-rc1-bin.tar.gz binutils-2.19-mingw32-rc1-src.tar.gz Then, if you get no negative reports within say four weeks, duplicate the files without the `-rc1' qualifier, add them into the same FRS release container, remove the `rc1' files, and rename the container as a `Current Release', (or create a new `Current Release', and hide the corresponding `Release Candidate', if you prefer). Regards, Keith. |
From: Earnie B. <ea...@us...> - 2008-11-01 12:08:32
|
Quoting Keith Marshall <kei...@us...>: > On Friday 31 October 2008 03:09:42 Chris Sutcliffe wrote: >> Now that binutils-2.19 is official, I'm working on creating a new >> release for MinGW. I'm assuming that now this is an 'official' >> release, I can mark this as current (replacing 2.17.50)? > > I'd be inclined to offer it initially as a `Release Candidate': > > binutils-2.19-mingw32-rc1-bin.tar.gz > binutils-2.19-mingw32-rc1-src.tar.gz > That's what we've done in the past. > Then, if you get no negative reports within say four weeks, duplicate > the files without the `-rc1' qualifier, add them into the same FRS > release container, remove the `rc1' files, and rename the container > as a `Current Release', (or create a new `Current Release', and hide > the corresponding `Release Candidate', if you prefer). > That's what we should have done in the past. Earnie |