From: Erwin W. <wat...@xs...> - 2011-10-12 20:40:58
|
Keith Marshall schreef, Op 12-10-2011 21:48: >> Libunistring compiles >> without problems, out-of-the-box, but at the very end the linking step >> ends with this error: >> >> ... >> glthread/.libs/lock.o:lock.c:(.text+0x14): undefined reference to >> `_imp__pthread_mutexattr_init' >> glthread/.libs/lock.o:lock.c:(.text+0x3d): undefined reference to >> ...more similar messages... >> collect2: ld returned 1 exit status >> make[2]: *** [libunistring.la] Error 1 >> >> Why is this last linking step going wrong? > I don't know. Curiously enough, I built libunistring myself today, and > noted a similar failure, (although I don't recall so many unresolved > references as you report, but those I did see were pthreads specific). > I worked around it by configuring with --enable-threads=win32, which, > after a 'make clean' resulted in a successful build. > Hi Keith, Thank you very much. This worked for me too. best regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Chris S. <ir0...@gm...> - 2011-10-18 12:51:12
|
On 18 October 2011 08:39, Earnie wrote: > Charles Wilson wrote: >> Well, that's really what I was asking: do we want to count all >> *contributors* as *project members*. Answer: probably not. Same with >> FRS access. > > I don't see a reason not to. If someone is contributing to MinGW they > have as much right to be listed as a project member as anyone else. The > controls give us the ability to choose what the project member can access. I thought FRS access was all or nothing. If that is indeed the case, do we want to give every contributor access to the entire FRS? Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Earnie <ea...@us...> - 2011-10-18 13:51:31
|
Chris Sutcliffe wrote: > On 18 October 2011 08:39, Earnie wrote: >> Charles Wilson wrote: >>> Well, that's really what I was asking: do we want to count all >>> *contributors* as *project members*. Answer: probably not. Same with >>> FRS access. >> >> I don't see a reason not to. If someone is contributing to MinGW they >> have as much right to be listed as a project member as anyone else. The >> controls give us the ability to choose what the project member can access. > > I thought FRS access was all or nothing. If that is indeed the case, > do we want to give every contributor access to the entire FRS? You can be a project member without having access to FRS. I wasn't rebutting the FRS access. On the other hand though if we do want to give someone FRS access they *must* be a project member. Earnie |
From: Erwin W. <wat...@xs...> - 2011-10-28 09:31:17
|
On 10/28/2011 5:15 AM, Charles Wilson wrote: > On 10/27/2011 3:39 PM, Erwin Waterlander wrote: >> I added a proposed xml manifest file: >> >> http://waterlan.home.xs4all.nl/mingw/mingw32-libunistring.xml.lzma >> >> http://waterlan.home.xs4all.nl/mingw/libunistring-0.9.3-1-mingw32-dev.tar.lzma >> http://waterlan.home.xs4all.nl/mingw/libunistring-0.9.3-1-mingw32-dll-0.tar.lzma >> http://waterlan.home.xs4all.nl/mingw/libunistring-0.9.3-1-mingw32-doc.tar.lzma >> http://waterlan.home.xs4all.nl/mingw/libunistring-0.9.3-1-mingw32-lic.tar.lzma >> http://waterlan.home.xs4all.nl/mingw/libunistring-0.9.3-1-mingw32-src.tar.lzma >> http://waterlan.home.xs4all.nl/mingw/libunistring-0.9.3-1-mingw32.RELEASE_NOTES.txt > Looks good. One minor quibble: for the -dev package, I'd add the > libunistring dll package as a<requires/>, but /not/ libgcc-dll or > libintl-dll. I mean, unistring.h doesn't really *require* libgcc-dll, > does it? That is: > > <component class="dev"> > <release tarname="libunistring-0.9.3-1-mingw32-dev.tar.lzma"> > -<requires eq="mingw32-libgcc-*-mingw32-dll-1.tar" /> > -<requires eq="mingw32-libiconv-*-mingw32-*-dll-2.tar" /> > +<requires eq="mingw32-libunistring-%-mingw32-%-dll-0.tar" /> > </release> > </component> Okay, fine. I also patched http://waterlan.home.xs4all.nl/mingw/mingw32-libunistring.xml.lzma > > Now, to skip ahead to the next question...when we upload this, should we > go ahead and move PDCurses into MinGW/Contributed/ as well? (Unless > somebody has an argument for why PDCurses should be "core") > I agree to put PDCurses also under MinGW/Contributed/ And perhaps remove UserContributed/pdcurses/Current Release_ pdcurses-2.6.0/? regards, Erwin |
From: Earnie <ea...@us...> - 2011-10-28 14:07:32
|
Erwin Waterlander wrote: > > I agree to put PDCurses also under MinGW/Contributed/ > And perhaps remove UserContributed/pdcurses/Current Release_ > pdcurses-2.6.0/? > Yes, on both counts. Earnie |
From: Erwin W. <wat...@xs...> - 2011-11-01 16:05:39
|
> [*] Pet peeve: please, when you upload to sf.net, or create new > directories, make sure the chmod all dirs as 775, and all files as 664. > Erwin "owns" the PDCurses directory (rwxr-xr-x), so I couldn't move it. > There are quite a few other dirs and files without group write > permission. If you have access to frs, please log on and fix the files > that you can. > I fixed it. I added group write permission to the PDCurses directories and files. regards, -- Erwin Waterlander |
From: Earnie <ea...@us...> - 2011-11-01 16:47:25
|
Erwin Waterlander wrote: > > >> [*] Pet peeve: please, when you upload to sf.net, or create new >> directories, make sure the chmod all dirs as 775, and all files as 664. >> Erwin "owns" the PDCurses directory (rwxr-xr-x), so I couldn't move it. >> There are quite a few other dirs and files without group write >> permission. If you have access to frs, please log on and fix the files >> that you can. >> > > I fixed it. I added group write permission to the PDCurses directories and > files. SF still doesn't have the correct? I thought they had fixed it once. Earnie P.S. Sarcastic remarks need no comment. |