From: Thomas S. <tks...@gm...> - 2010-09-15 05:15:00
|
My MinGW (recently updated with mingw-get to gcc 4.5) has headers and an export library for the pthread POSIX threading library, but no pthreadGC2.dll. I finally found it at the sourceware.org ftp site; but why was it not in the MinGW distribution? Cheers, Tom |
From: Charles W. <cwi...@us...> - 2010-09-15 05:48:48
|
On 9/15/2010 1:14 AM, Thomas Sharpless wrote: > My MinGW (recently updated with mingw-get to gcc 4.5) has headers and an > export library for the pthread POSIX threading library, but no > pthreadGC2.dll. I finally found it at the sourceware.org ftp site; but why > was it not in the MinGW distribution? MinGW gcc-4.5.0 ships with "libpthread-2.dll", not pthreadGC2.dll. The headers are the same. If you have an import library for the latter, then it is a leftover from an earlier version of MinGW gcc; the current pthread import lib specifies libpthread-2.dll: dlltool --identify libpthread.dll.a libpthread-2.dll Hmmm...it looks like the mingw32-pthreads-w32-dev is not installed by mingw32-gcc4. I think that's a mistake; it should be installed automatically. Try mingw-get install mingw32-pthreads-w32-dev mingw-get install mingw32-libpthread-dll <<< this IS installed by default -- Chuck |
From: Thomas S. <tks...@gm...> - 2010-09-16 01:51:20
|
Thanks, Chuck The installs you recommended got pthread.h, sched.h and libpthread_2.dll OK. But I don't see a new semaphore.h -- do I need to install another package to get that? The old headers are in c:/mingw/mingw32/include, while the new ones went into c:/mingw/include. Likewise for the import lib. Has there been a change in the official directory structure? The mingw that came with my Qt 4.6 -- which I have not touched -- has the old arrangement, and no pthreads dll (but of course Qt wouldn't need that). I'm still rather in the dark about mingw-get. Is there a good human-readable list of the MinGW packages and what they contain? And what are the preconditions for using it to update Msys? BTW I ran into a nasty little problem with gcc 4.5, sys/types.h and sched.h when building FFmpeg. sched.h is one of many bits of useful code that use old not_prefixed_with_underscore names for common system and C lib items. FFmpeg's build scripts pass --std=c99 to gcc, which now causes it to automatically #define _NO_OLDNAMES, which prevents sys/types.h from defining pid_t; however sched.h assumes that including sys/types.h will always define pid_t. It uses a fallback definition when it doesn't include sys/types.h, but does not detect the case that pid_t is undefined when it does. My fix is to make sched.h apply the fallback whenever pid_t is undefined. FFmpeg really should not claim ANSI purity, it uses old names several places in libavformat; but I am not about to mess with an autoconf script. Regards, Tom On Wed, Sep 15, 2010 at 1:47 AM, Charles Wilson < cwi...@us...> wrote: > On 9/15/2010 1:14 AM, Thomas Sharpless wrote: > > My MinGW (recently updated with mingw-get to gcc 4.5) has headers and an > > export library for the pthread POSIX threading library, but no > > pthreadGC2.dll. I finally found it at the sourceware.org ftp site; but > why > > was it not in the MinGW distribution? > > MinGW gcc-4.5.0 ships with "libpthread-2.dll", not pthreadGC2.dll. The > headers are the same. If you have an import library for the latter, > then it is a leftover from an earlier version of MinGW gcc; the current > pthread import lib specifies libpthread-2.dll: > > dlltool --identify libpthread.dll.a > libpthread-2.dll > > > Hmmm...it looks like the mingw32-pthreads-w32-dev is not installed by > mingw32-gcc4. I think that's a mistake; it should be installed > automatically. > > Try > > mingw-get install mingw32-pthreads-w32-dev > mingw-get install mingw32-libpthread-dll <<< this IS installed by > default > > > -- > Chuck > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > 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 > |
From: Thomas S. <tks...@gm...> - 2010-09-16 03:32:03
|
Update on that ANSI purity problem. I now realize it's best to leave the mingw headers as written, and fix the ffmpeg build scripts instead. Doing that, I found that I had to remove all of the following flags to get ffmpeg to compile without error: -std=C99, -D_ISOC99_SOURCE, -D_POSIX_C_SOURCE=200112 Apparently gcc 4.5 defines _NO_OLDNAMES, __STRICT_ANSI__ or both when it sees any of them. The good news is that without them it compiles over twice as fast. Although build definitely used the new pthread headers and import library, the runtime still wants "pthreadGC2.dll". A symbolic link to the new libpthread-2.dll satisfies it (though I have not yet run any of the multithreaded codecs). Any ideas? Cheers, Tom On Wed, Sep 15, 2010 at 9:51 PM, Thomas Sharpless <tks...@gm...>wrote: > Thanks, Chuck > > The installs you recommended got pthread.h, sched.h and libpthread_2.dll > OK. But I don't see a new semaphore.h -- do I need to install another > package to get that? > > The old headers are in c:/mingw/mingw32/include, while the new ones went > into c:/mingw/include. Likewise for the import lib. Has there been a > change in the official directory structure? The mingw that came with my Qt > 4.6 -- which I have not touched -- has the old arrangement, and no pthreads > dll (but of course Qt wouldn't need that). > > I'm still rather in the dark about mingw-get. Is there a good > human-readable list of the MinGW packages and what they contain? And what > are the preconditions for using it to update Msys? > > BTW I ran into a nasty little problem with gcc 4.5, sys/types.h and sched.h > when building FFmpeg. sched.h is one of many bits of useful code that use > old not_prefixed_with_underscore names for common system and C lib items. > FFmpeg's build scripts pass --std=c99 to gcc, which now causes it to > automatically #define _NO_OLDNAMES, which prevents sys/types.h from defining > pid_t; however sched.h assumes that including sys/types.h will always define > pid_t. It uses a fallback definition when it doesn't include sys/types.h, > but does not detect the case that pid_t is undefined when it does. My fix > is to make sched.h apply the fallback whenever pid_t is undefined. > > FFmpeg really should not claim ANSI purity, it uses old names several > places in libavformat; but I am not about to mess with an autoconf script. > > Regards, Tom > > > > On Wed, Sep 15, 2010 at 1:47 AM, Charles Wilson < > cwi...@us...> wrote: > >> On 9/15/2010 1:14 AM, Thomas Sharpless wrote: >> > My MinGW (recently updated with mingw-get to gcc 4.5) has headers and >> an >> > export library for the pthread POSIX threading library, but no >> > pthreadGC2.dll. I finally found it at the sourceware.org ftp site; but >> why >> > was it not in the MinGW distribution? >> >> MinGW gcc-4.5.0 ships with "libpthread-2.dll", not pthreadGC2.dll. The >> headers are the same. If you have an import library for the latter, >> then it is a leftover from an earlier version of MinGW gcc; the current >> pthread import lib specifies libpthread-2.dll: >> >> dlltool --identify libpthread.dll.a >> libpthread-2.dll >> >> >> Hmmm...it looks like the mingw32-pthreads-w32-dev is not installed by >> mingw32-gcc4. I think that's a mistake; it should be installed >> automatically. >> >> Try >> >> mingw-get install mingw32-pthreads-w32-dev >> mingw-get install mingw32-libpthread-dll <<< this IS installed by >> default >> >> >> -- >> Chuck >> >> >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing. >> http://p.sf.net/sfu/novell-sfdev2dev >> _______________________________________________ >> 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 >> > > |
From: Charles W. <cwi...@us...> - 2010-09-16 04:16:29
|
On 9/15/2010 9:51 PM, Thomas Sharpless wrote: > Thanks, Chuck > > The installs you recommended got pthread.h, sched.h and libpthread_2.dll > OK. But I don't see a new semaphore.h -- do I need to install another > package to get that? No. It is in that package: $ tar tJf ../var/cache/mingw-get/packages/pthreads-w32-2.8.0-3-mingw32-dev.tar.lzma include/ include/pthread.h include/sched.h include/semaphore.h <<<<< right here. lib/ lib/libpthread.dll.a If semaphore.h didn't get unpacked, I'd check <installation_root>/var/cache/mingw-get/packages/ and verify the tarball, as I've done above. I'm going to assume that "libpthread_2.dll" was a typo; the file is: $ tar tJf ../var/cache/mingw-get/packages/libpthread-2.8.0-3-mingw32-dll-2.tar.lzma bin/libpthread-2.dll > The old headers are in c:/mingw/mingw32/include, while the new ones went > into c:/mingw/include. Likewise for the import lib. Has there been a > change in the official directory structure? Yes, there has. In that very early prototype version, the basic runtime support stuff was put into the ${prefix}/${host}/{include,lib} directories, where on MinGW, prefix is usually C:\MinGW, and $host was defined as the alias "mingw32" instead of the fully qualified platform triple "i686-pc-mingw32". However, in the new releases, everything goes into ${prefix}/{include,lib} just like on unix. > The mingw that came with my Qt > 4.6 -- which I have not touched -- has the old arrangement, and no pthreads > dll (but of course Qt wouldn't need that). I don't mean to be rude, but we really can't support anything -- even if it calls itself "mingw" -- that is distributed by somebody else. We have no idea what they have done... > I'm still rather in the dark about mingw-get. Is there a good > human-readable list of the MinGW packages and what they contain? Well, not as such, no. However the manifests themselves are just XML files, and are in plain english. Take a look here: https://sourceforge.net/projects/mingw/files_beta/Automated%20MinGW%20Installer/mingw-get/catalogue/ OR, install a new MinGW/MSYS somewhere using mingw-get-inst, and look in <installation_root>/var/lib/mingw-get/data/ All the .xml manifests live there (ignore the ones whose names contain bunch of hex digits). One of the primary goals for mingw-get in the short- to medium-term is to add 'mingw-get show' (or list, or search, or something like that) that can do what you ask. Patches Thoughtfully Considered. > And what > are the preconditions for using it to update Msys? It's best if you don't try to use mingw-get to "update" anything that wasn't originally INSTALLED by mingw-get. You're better off starting "fresh" with a new mingw-get-created installation. > BTW I ran into a nasty little problem ... Ignoring this bit, as you've already found an alternate solution. -- Chuck |
From: Thomas S. <tks...@gm...> - 2010-09-16 14:22:16
|
Chuck, Thanks again. Yes, semaphore.h did get installed, I just overlooked it. Oddly enough, despite the new headers and implib, the ffmpeg runtime still wants pthreadGC2.dll. A symbolic link to libpthread-2.dll satisfies it; but why do you think this happened? There are no prebuilt libraries in this build, aside from the ones supplied by MinGW. I would like to try setting up a complete new MinGW/MSYS with mingw-get. What is the correct incantation for that? Regards, Tom On Thu, Sep 16, 2010 at 12:15 AM, Charles Wilson < cwi...@us...> wrote: > On 9/15/2010 9:51 PM, Thomas Sharpless wrote: > > Thanks, Chuck > > > > The installs you recommended got pthread.h, sched.h and libpthread_2.dll > > OK. But I don't see a new semaphore.h -- do I need to install another > > package to get that? > > No. It is in that package: > > $ tar tJf > ../var/cache/mingw-get/packages/pthreads-w32-2.8.0-3-mingw32-dev.tar.lzma > include/ > include/pthread.h > include/sched.h > include/semaphore.h <<<<< right here. > lib/ > lib/libpthread.dll.a > > If semaphore.h didn't get unpacked, I'd check > <installation_root>/var/cache/mingw-get/packages/ and verify the > tarball, as I've done above. > > I'm going to assume that "libpthread_2.dll" was a typo; the file is: > > $ tar tJf > ../var/cache/mingw-get/packages/libpthread-2.8.0-3-mingw32-dll-2.tar.lzma > bin/libpthread-2.dll > > > > The old headers are in c:/mingw/mingw32/include, while the new ones went > > into c:/mingw/include. Likewise for the import lib. Has there been a > > change in the official directory structure? > > Yes, there has. In that very early prototype version, the basic runtime > support stuff was put into the ${prefix}/${host}/{include,lib} > directories, where on MinGW, prefix is usually C:\MinGW, and $host was > defined as the alias "mingw32" instead of the fully qualified platform > triple "i686-pc-mingw32". > > However, in the new releases, everything goes into > ${prefix}/{include,lib} just like on unix. > > > The mingw that came with my Qt > > 4.6 -- which I have not touched -- has the old arrangement, and no > pthreads > > dll (but of course Qt wouldn't need that). > > I don't mean to be rude, but we really can't support anything -- even if > it calls itself "mingw" -- that is distributed by somebody else. We > have no idea what they have done... > > > I'm still rather in the dark about mingw-get. Is there a good > > human-readable list of the MinGW packages and what they contain? > > Well, not as such, no. However the manifests themselves are just XML > files, and are in plain english. Take a look here: > > > https://sourceforge.net/projects/mingw/files_beta/Automated%20MinGW%20Installer/mingw-get/catalogue/ > > OR, install a new MinGW/MSYS somewhere using mingw-get-inst, and look in > <installation_root>/var/lib/mingw-get/data/ All the .xml manifests > live there (ignore the ones whose names contain bunch of hex digits). > > One of the primary goals for mingw-get in the short- to medium-term is > to add 'mingw-get show' (or list, or search, or something like that) > that can do what you ask. Patches Thoughtfully Considered. > > > And what > > are the preconditions for using it to update Msys? > > It's best if you don't try to use mingw-get to "update" anything that > wasn't originally INSTALLED by mingw-get. You're better off starting > "fresh" with a new mingw-get-created installation. > > > BTW I ran into a nasty little problem ... > > Ignoring this bit, as you've already found an alternate solution. > > -- > Chuck > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > 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 > |
From: Charles W. <cwi...@us...> - 2010-09-17 02:42:03
|
On 9/16/2010 10:22 AM, Thomas Sharpless wrote: > Oddly enough, despite the new headers and implib, the ffmpeg runtime still > wants pthreadGC2.dll. Then you are using the wrong import library. BTW, if you are using the mingw64 project's libpthread.dll.a by mistake, you would end up with a dependency on their pthreadGC2.dll. But, if you are actually using *our* libpthread.dll.a, then you WILL end up with a dependency on *our* libpthread-2.dll. That's what this means: $ dlltool --identify /mingw/lib/libpthread.dll.a libpthread-2.dll > A symbolic link to libpthread-2.dll satisfies it; Remember that in MSYS, there is no such thing as a symbolic link. If you do "ln -s target link", then link will be created as a *hard*link to the same data as target (if both files are one the same device) or a copy of target. > but > why do you think this happened? You're still using an old libpthread.dll.a, or you've gotten a mingw64 installation mixed up into you mingw.org one. > There are no prebuilt libraries in this > build, aside from the ones supplied by MinGW. > > I would like to try setting up a complete new MinGW/MSYS with mingw-get. > What is the correct incantation for that? Move your old installation somewhere safe (I assume it's under C:\MinGW and C:\msys\1.0). Them, download mingw-get-inst-20100909.exe and run it. Answer the questions. Done (if all goes well). The end. -- Chuck |
From: Thomas S. <tks...@gm...> - 2010-09-17 14:02:50
|
Hi Chuck On Thu, Sep 16, 2010 at 10:40 PM, Charles Wilson < cwi...@us...> wrote: > On 9/16/2010 10:22 AM, Thomas Sharpless wrote: > > Oddly enough, despite the new headers and implib, the ffmpeg runtime > still > > wants pthreadGC2.dll. > > Then you are using the wrong import library. BTW, if you are using the > mingw64 project's libpthread.dll.a by mistake, you would end up with a > dependency on their pthreadGC2.dll. But, if you are actually using > *our* libpthread.dll.a, then you WILL end up with a dependency on *our* > libpthread-2.dll. That's what this means: > > $ dlltool --identify /mingw/lib/libpthread.dll.a > libpthread-2.dll > That is what I get when I run this command in MSYS. > > > A symbolic link to libpthread-2.dll satisfies it; > > Remember that in MSYS, there is no such thing as a symbolic link. If you > do "ln -s target link", then link will be created as a *hard*link to the > same data as target (if both files are one the same device) or a copy of > target. > > I'm on WinVista, which (like Win7) supports symlinks made with the Windows shell. > but > > why do you think this happened? > > You're still using an old libpthread.dll.a, or you've gotten a mingw64 > installation mixed up into you mingw.org one. > So I shall just have to hunt down the incorrect implib. > > > There are no prebuilt libraries in this > > build, aside from the ones supplied by MinGW. > > > > I would like to try setting up a complete new MinGW/MSYS with mingw-get. > > What is the correct incantation for that? > > Move your old installation somewhere safe (I assume it's under C:\MinGW > and C:\msys\1.0). > > Them, download mingw-get-inst-20100909.exe and run it. Answer the > questions. Done (if all goes well). The end. > > Did that. (Wow, there's a lot more in the new MinGW than I thought.) Rebuild ffmpeg now fails with ld not finding "-lpthreadGC2" -- as it should. Thanks again, Tom -- > Chuck > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > 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 > |
From: Maurício G. <ors...@gm...> - 2010-09-15 05:50:39
|
Someone actually know how I make a program don't depend on mingwsomething.dll and pthreadGC2.dll? (I mean, static link those) On Wed, Sep 15, 2010 at 2:14 AM, Thomas Sharpless <tks...@gm...>wrote: > My MinGW (recently updated with mingw-get to gcc 4.5) has headers and an > export library for the pthread POSIX threading library, but no > pthreadGC2.dll. I finally found it at the sourceware.org ftp site; but > why was it not in the MinGW distribution? > > Cheers, Tom > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > 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 > |
From: Charles W. <cwi...@us...> - 2010-09-17 14:40:40
|
On 9/17/2010 10:02 AM, Thomas Sharpless wrote: > Rebuild ffmpeg now fails with ld not finding "-lpthreadGC2" -- as it > should. Ah, well that explains some things. ld has the ability to link *directly* to a DLL, without using an import lib at all. So, if the Makefile includes a command that tells ld to link *directly to pthreadGC2.dll*, then it will do so. That's the mistake. Instead of -lpthreadGC2, change that to -lpthread and all should be well. -- Chuck |
From: Thomas S. <tks...@gm...> - 2010-09-19 19:40:39
|
Hi Chuck On Fri, Sep 17, 2010 at 10:39 AM, Charles Wilson < cwi...@us...> wrote: > On 9/17/2010 10:02 AM, Thomas Sharpless wrote: > > Rebuild ffmpeg now fails with ld not finding "-lpthreadGC2" -- as it > > should. > > Ah, well that explains some things. ld has the ability to link > *directly* to a DLL, without using an import lib at all. So, if the > Makefile includes a command that tells ld to link *directly to > pthreadGC2.dll*, then it will do so. > > That's the mistake. > > Instead of -lpthreadGC2, change that to -lpthread and all should be well. > Right. I found the bit deep down in the ffmpeg build scripts that specified pthreadgc2 and changed it. All building OK now. Regards, Tom > -- > Chuck > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > 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 > |