From: Soren A <sor...@fa...> - 2002-09-26 17:34:20
|
Earnie Boyd <ear...@ya...> wrote around 25 Sep 2002 news:3D9...@ya...: [Message-ID: <3D9...@ya...> References: <Xns9294A75257AF8soren1Gmane@80.91.224.249>] > Once I have a libtool that properly supports win32 shared and static > libs, it should be smoother water. The glib site has pointers to a > Win32 prebuild version, currently requires VS MSVC++. With this old release of glib that's packaged with pkgconfig -- 1.2.8 -- I actually have made a libglib.a as of 5 minutes ago. So far the source hacking is minimal. I know it may be completely different from what you are focusing on right now, but I'd like to ask your advice. I am just trying to get a static lib built so that I can get a working pkgconfig.exe running. I am getting about 100 lines of this: ./.libs/libglib.a(gnode.o)(.text+0x3d1):gnode.c: undefined reference to `_imp__g_thread_functions_for_glib_use' When I try to `make' (the build tries a test program linking to glib to verify its wholesomeness, after creating libglib.la). Maybe I should turn off threads entirely? Threads on MinGW -- threads in general -- are a complete mystery to me. glib seems to imply that it has thread support for win32. But something is missing. Is it a linker flag that the libtool built for glib doesn't know about? Any ideas? Is it '-mthreads' perhaps? I did 'configure' with these params: $ CC=gcc CFLAGS='-O2 -Wundef -Wmissing-declarations' ./configure \ --with-gnu-ld --cache-file=config.cache --prefix='/d/topusrlocal' The step where make is failing prints: (cd .libs && rm -f libglib.la && ln ../libglib.la libglib.la) /bin/sh ./libtool --mode=link gcc -O2 -Wundef -Wmissing-declarations -Wall -o testglib testglib.o libglib.la gcc -O2 -Wundef -Wmissing-declarations -Wall -o testglib testglib.o ./.libs/libglib.a Yep, no '-mthreads' there. If I add '-mthreads' to the commands at the linking step: "make CPPFLAGS='-DNATIVE_WIN32=1' LDFLAGS='-mthreads'" ... nope, no help. I dunno, I bet there's much more pitfallish stuff after this one, maybe it's not worth asking for diagnostic help on this, but since I started this message I might as well 'send'... No, didn't hit "send", I worked for another evening on it. I downloaded a pre-built glib. It doesn't work too well: pkg-config sometimes crashes the sh console on my Win98 (I think this is because it's built with MSVC and I see this sometimes with such, but ONLY on Win9x). So, anybody got any ideas about gthreads? I am Google'ing as I type this... Thanks, Soren A |
From: Earnie B. <ear...@ya...> - 2002-09-26 18:45:48
|
Soren A wrote: > > Earnie Boyd <ear...@ya...> wrote around 25 Sep 2002 > news:3D9...@ya...: > > [Message-ID: <3D9...@ya...> > References: <Xns9294A75257AF8soren1Gmane@80.91.224.249>] > > > Once I have a libtool that properly supports win32 shared and static > > libs, it should be smoother water. The glib site has pointers to a > > Win32 prebuild version, currently requires VS MSVC++. > > With this old release of glib that's packaged with pkgconfig -- 1.2.8 -- > I actually have made a libglib.a as of 5 minutes ago. So far the source > hacking is minimal. I know it may be completely different from what you > are focusing on right now, but I'd like to ask your advice. > > I am just trying to get a static lib built so that I can get a working > pkgconfig.exe running. I am getting about 100 lines of this: > > ./.libs/libglib.a(gnode.o)(.text+0x3d1):gnode.c: undefined reference to > `_imp__g_thread_functions_for_glib_use' > _imp_ is requesting the import symbol for the mangled name _g_thread_functions_for_glib_use. _imp_ implies a dll. You need to get glib built as a dll. Earnie. |
From: Tor L. <tm...@ik...> - 2002-09-26 18:49:06
|
Soren A writes: > With this old release of glib that's packaged with pkgconfig -- 1.2.8 -- > I actually have made a libglib.a as of 5 minutes ago. > [...] > Maybe I should turn off threads entirely? Threads on MinGW -- threads in > general -- are a complete mystery to me. glib seems to imply that it has > thread support for win32. But something is missing. There is a reason, you know, why the suggested way to build pkg-config on Windows is to use GLib 2.0.x, and not the included glib-1.2.8. At GLib 1.2.8's time, the Win32 support in GLib was much less stable than what it is now. For thread support it used the pthreads-win32 package. Now it uses the Win32 API directly. > I worked for another evening on it. I downloaded a pre-built > glib. It doesn't work too well: pkg-config sometimes crashes the sh > console on my Win98 (I think this is because it's built with MSVC > and I see this sometimes with such, but ONLY on Win9x). Hmm. The MSYS sh crashes when you run pkg-config? Odd... pkg-config doesn't do anything strange, just reads files and writes to stdout, more or less. --tml |
From: Earnie B. <ear...@ya...> - 2002-09-26 19:13:53
|
Tor Lillqvist wrote: > > > I worked for another evening on it. I downloaded a pre-built > > glib. It doesn't work too well: pkg-config sometimes crashes the sh > > console on my Win98 (I think this is because it's built with MSVC > > and I see this sometimes with such, but ONLY on Win9x). > > Hmm. The MSYS sh crashes when you run pkg-config? Odd... pkg-config > doesn't do anything strange, just reads files and writes to stdout, > more or less. > Known problem with the 1.0.8 snapshot. Earnie. |
From: Soren A <sor...@fa...> - 2002-09-26 20:05:36
|
Earnie Boyd <ear...@ya...> wrote around 26 Sep 2002 news:3D9...@ya...: > > Known problem with the 1.0.8 snapshot. It IS? I didn't know that. If you'll read my follow-up to Tor's message, to make sure ... Thanks, Soren A |
From: Earnie B. <ear...@ya...> - 2002-09-26 21:12:39
|
Soren A wrote: > > Earnie Boyd <ear...@ya...> wrote around 26 Sep 2002 > news:3D9...@ya...: > > > > > Known problem with the 1.0.8 snapshot. > > It IS? I didn't know that. If you'll read my follow-up to Tor's message, to > make sure ... > Ah, that's a different issue. Does your video controller use portions of RAM to extend itself? How much memory do you have? How much free disk space do you have? Earnie. |
From: Soren A <sor...@fa...> - 2002-09-26 22:10:50
|
Earnie Boyd <ear...@ya...> wrote around 26 Sep 2002 news:3D9...@ya...: > Ah, that's a different issue. Does your video controller use portions > of RAM to extend itself? How much memory do you have? How much free > disk space do you have? None of those have anything to do with it. This has been happening to me through changes of video controllers and on completely different systems, for years (as long as it has been Win9x tho). I'd wager hugely that this isn't even close to the right tree to begin barking up. Thanks, Soren A |
From: Soren A <sor...@fa...> - 2002-09-26 20:10:52
|
Tor Lillqvist <tm...@ik...> wrote around 26 Sep 2002 news:157...@ga...rgle.HOWL: > Soren A writes: > > With this old release of glib that's packaged with pkgconfig -- > > 1.2.8 -- I actually have made a libglib.a as of 5 minutes ago. > > [...] > > Maybe I should turn off threads entirely? Threads on MinGW -- > > threads in general -- are a complete mystery to me. glib seems to > > imply that it has thread support for win32. But something is > > missing. > > There is a reason, you know, why the suggested way to build pkg-config > on Windows is to use GLib 2.0.x, and not the included glib-1.2.8. At > GLib 1.2.8's time, the Win32 support in GLib was much less stable than > what it is now. For thread support it used the pthreads-win32 package. > Now it uses the Win32 API directly. OK. Thanks! But that just creates a different set of problems for me. Yet I very much appreciate it. Now I will know to focus all my energy on building Glib 2.0.x instead of trying to get this old Glib going. BTW, Tor, I didn't know you would be reading this List. Thanks for all your groundbreaking work on GTk+ and GIMP for Windows. > > I worked for another evening on it. I downloaded a pre-built > > glib. It doesn't work too well: pkg-config sometimes crashes the sh > > console on my Win98 (I think this is because it's built with MSVC > > and I see this sometimes with such, but ONLY on Win9x). > > Hmm. The MSYS sh crashes when you run pkg-config? Odd... pkg-config > doesn't do anything strange, just reads files and writes to stdout, > more or less. About the following: Earnie has just posted that "it's a known problem on snapshot 1.0.8 of MSYS". So perhaps most readers can skip that part. But there's something else directed to Tor below that. --------------------------------------------- That's what I would have thought. The crashing is a thing I have seen ever since I started using Cygwin, MinGW/MSYS etc. I have written about it in various places and no-one knows why it happens. It is a strange kind of "crash". It is manifest as an immediate video corruption of the screen in which it displays blocks of colored rectangles (each character cell of the console) with odd symbols (raw beyond-ascii bytes) in each one. Sometimes one can gracefully exit the shell by typing "exit" blind (unable to see what's on the console anymore) and sometimes it is frozen and you must force Windows to close it with a 3-fingered salute (CTRL-ALT-DEL). This mostly happens when trying to run Perl module builds in sh-ish shell, or when the Windows subdir command/ is in the PATH. My speculation is that it has to do with COMMAND.COM being summoned as a subshell, and with the inability of COMMAND.COM to handle output redirection (Perl Makefiles typically run an I/O redirection as part of the complex sequence of things MakeMaker does...). The impact of that is completely evil. Anyway, this is a problem with MSYS and Cygwin that's never been documented or explained and because most of the major maintainers work only on NT-ish Windows, they won't be impacted by it. So it will remain a mystery. I have spent probably 100+ hours now trying to investigate and search for clues and have come up empty. It *won't happen* with your binary pkg-config is you just do $ pkg-config --version It *will* happen as soon as you _really_ try to use it, i.e. offer it a module name as an argument to query the *.pc files. Same happened when I linked my compiled object files in with your Glib.DLL to create a new pkg-config.exe. So that tells me that the trouble is in Glib on Win32, either in how it is written or in how it was built (using MSVC++). My guess is the latter. I am gambling on it being the latter because I have no idea how to fix it if it's the former; but if it is going to go away by building my own Glib then I am betting that with sufficient sweat I can accomplish that. --------- different topic --------------- BTW, Tor, *why* are Windows DLLs being used from subdirectories named "lib/" instead of "bin/" on your site? I know you aren't responsible for all the dependencies (iconv, etc...). I am just asking if you are aware that this isn't appropriate on a basic level; a Win32 DLL is NOT wholly analogous to a *nix .so share library -- it is in an internal sense a stand-alone executable -- and belongs with the other .exe files in dir named bin/. The *import libs* as they are called, foo.dll.[a|lib], are what belong in a subdir named /lib. Regards, Soren A |
From: Tor L. <tm...@ik...> - 2002-09-26 20:41:56
|
Soren A writes: > So that tells me that the trouble is in Glib on Win32, either in > how it is written or in how it was built (using MSVC++). No, the glib and other DLLs I distribute are built with mingw. > BTW, Tor, *why* are Windows DLLs being used from subdirectories > named "lib/" instead of "bin/" on your site? Umm, because that's where 'libtool --mode=install' puts them when invoked from the Makefiles produced from the cross-platform Makefile.am files... BTW, see Max Bowsher's message earlier today on this list (Libtool patch sticking point). > I am just asking if you are aware that this isn't appropriate on a > basic level; a Win32 DLL is NOT wholly analogous to a *nix .so > share library -- it is in an internal sense a stand-alone > executable -- and belongs with the other .exe files in dir named > bin/. The *import libs* as they are called, foo.dll.[a|lib], are > what belong in a subdir named /lib. Yes, I understand. But I don't find this so important that I would want to hack libtool or add complex workarounds to the Makefile.am files just to get the DLLs installed in $bindir. (Making the GLib etc Makefile.am files install the import libraries, too, was complex enough, this is IMHO really something that libtool should take care of automatically when it installs the DLL.) Invoking configure with --libdir=<prefix>/bin would be a possibility, but then the subdirectories of libdir (for instance GTK 2.0's lib/gtk-2.0/2.0.0/loaders) would get installed in bindir instead, which might be confusing, too. Besides, if somebody would look at it from a pure Windows perspective without any Unix background at all, using folder names like "bin" is a bit odd, too... And, the zipfiles I distribute aren't really meant for end-users. Software for end-users typically is installed with an installer, and the person building an installer can of course arrange for the DLLs to go in bin (or wherever) as she chooses. Only thing to look out for is that some DLLs (glib, gtk, pango) deduce their installation location at run-time in DllMain(). Message catalogs are looked up in <top>/lib/locale, for instance. If the DLL is in a "bin" or "lib" subfolder, the parent folder of that is assumed to be the <top>, otherwise, the DLL is assumed to be directly in <top>. --tml |
From: Soren A <sor...@fa...> - 2002-09-26 18:58:38
|
Sorry! Updating myself: > So, anybody got any ideas about gthreads? I am Google'ing as I type > this... Trying to learn too much new terminology WAY too fast. I SEE now, that Glib is using *pthreads* to do thread support (internally what it is calling "gthreads") on Win32. Aha. And prebuilt pthreads files are available at ftp://sources.redhat.com/pub/pthreads-win32/dll-latest So maybe just maybe I'll make some progress after all. Certainly, trying to build Glib without thread support doesn't seem to work: internally the code modules don't seem to be set up for it. A very confusing package, this. ----------------------------- Previously I wrote: Soren A <soren_andersen=97j...@pu...> wrote around 26 Sep 2002 news:Xns92958A088775Asoren1Gmane@80.91.224.249: > > Yep, no '-mthreads' there. If I add '-mthreads' to the commands at the > linking step: "make CPPFLAGS='-DNATIVE_WIN32=1' LDFLAGS='-mthreads'" > ... nope, no help. > > I dunno, I bet there's much more pitfallish stuff after this one, > maybe it's not worth asking for diagnostic help on this, but since I > started this message I might as well 'send'... > > No, didn't hit "send", I worked for another evening on it. I > downloaded a pre-built glib. It doesn't work too well: pkg-config > sometimes crashes the sh console on my Win98 (I think this is because > it's built with MSVC and I see this sometimes with such, but ONLY on > Win9x). |
From: Soren A <sor...@fa...> - 2002-09-26 21:58:25
|
Whoops, I misunderstood about you being an MSVC user. When I saw all those libraries named ".lib" it reinforced my assumption. That's surely not what I expect to see from a gcc user. Also - Tor Lillqvist <tm...@ik...> wrote around 26 Sep 2002 news:157...@ga...rgle.HOWL: > > BTW, Tor, *why* are Windows DLLs being used from subdirectories > > named "lib/" instead of "bin/" on your site? > > Umm, because that's where 'libtool --mode=install' puts them when > invoked from the Makefiles produced from the cross-platform > Makefile.am files... BTW, see Max Bowsher's message earlier today on > this list (Libtool patch sticking point). OK, I will, and see below where I acknowledge all the pointing towards libtool. > > I am just asking if you are aware that this isn't appropriate on a > > basic level; a Win32 DLL is NOT wholly analogous to a *nix .so > > share library -- it is in an internal sense a stand-alone > > executable -- and belongs with the other .exe files in dir named > > bin/. The *import libs* as they are called, foo.dll.[a|lib], are > > what belong in a subdir named /lib. > > Yes, I understand. But I don't find this so important that I would > want to hack libtool or add complex workarounds to the Makefile.am > files just to get the DLLs installed in $bindir. I am going to shock everyone by restraining myself from going off on what I think of Automake. On THIS occasion. I reserve the right to rant again on another. But as far as whether it is important or not: to me, it would be. I've been using Cygwin and MinGW for years now and carefully trying to learn from the gurus (Charles Wilson, etc.) all about how we do this DLL thing on windows32. Because these are now very widely used build platforms, a de-facto standard now exists. DLLs go in a directory wherein we expect to find exes (which also happens to be the first place the Windows OS will look for the DLL at runtime if the exe linking to it is in that directory; in this sense, the standard existed all along in how MS does it too). A place that the user's PATH probably already points to. So what's confusing is when a lot of people (a user base) have expectations of things being a certain way and then encounters something at variance with that. I submit that avoiding that kind of confusion would be, for me, a pretty high priority. Looking at Gtk+ / Glib etc. in isolation, I am sure that this among the many decisions you've had to make doesn't look very important. But looking at it in a larger context it is decidedly not what these middle-ground experts -- MinGW and Cygwin users of some time of experience at least -- will expect. > (Making the GLib etc Makefile.am files install the import libraries, > too, was complex enough, this is IMHO really something that libtool > should take care of automatically when it installs the DLL.) > Invoking configure with --libdir=<prefix>/bin would be a possibility, > but then the subdirectories of libdir (for instance GTK 2.0's > lib/gtk-2.0/2.0.0/loaders) would get installed in bindir instead, > which might be confusing, too. So it all comes back to getting libtool to work, which is what Earnie and Max have been saying. Meanwhile I am just TOO impatient to wait ... of course. > Besides, if somebody would look at it from a pure Windows perspective > without any Unix background at all, using folder names like "bin" is a > bit odd, too... Oh, well, if you want to go THERE, it's all a huge kludge isn't it ;-). But the point isn't what the directory is called -- although in a Cygwin or MinGW installation many users will be using /usr/local as a prefix for stuff they build themselves, there's nothing forcing that on anyone. But the packages that comprise the Cygwin and MSYS setups definitely have a conventional install location prefix (under root / which has /usr as a synonym). It's now a pretty widely-understood convention. As with all such conventions, it's purpose is simply to make life a bit easily for the user of software ported from *nix. My point about DLLs is that there's limit to how far one ought to go in imposing a *nix template on windows32. When there's a righteous analogy happening, exploit it -- but when there is a very large underlying difference between "how things work" on windows32 vs *nix, one mustn't be caught out slavishly try to force the round peg into the square hole. Boy I hope readers were able to keep straight my metaphor wrapped around my analogy ;-). Or was it the other way around... Best, Soren A |
From: Tor L. <tm...@ik...> - 2002-09-27 06:00:05
|
(Sorry for not replying to all of your points now; in a bit of a hurry.) Soren A writes: > Whoops, I misunderstood about you being an MSVC user. When I saw all > those libraries named ".lib" it reinforced my assumption. That's surely > not what I expect to see from a gcc user. I do have access (at work) to Microsoft's linker, and I use it to produce import libraries for MSVC users, too. The same GLib etc DLLs are perfectly useable from MSVC-compiled code, too, so there is no good reason not to provide import libraries for MSVC. (Except that it's somewhat of a hassle to have to produce them on another machine. OTOH, with the interface of GLib 2.0.x being frozen, it isn't often that new import libraries have to be produced.) > But the packages that comprise the Cygwin and MSYS setups definitely > have a conventional install location prefix (under root / which has /usr > as a synonym). It's now a pretty widely-understood convention. > As with all such conventions, it's purpose is simply to make life a > bit easily for the user of software ported from *nix. Ah, yes, but understand that for software like GIMP and Dia, the majority of end-users on Windows have no idea of what mingw, MSYS, GLib, or even a compiler is. They are not necessarily aware at all that the software is ported from *nix, or that having executables (DLLs) in a folder called "lib" would be somehow strange. (They probably never have checked where other software installs its DLLs, if they know what a DLL is.) They just want a tool that works. If the installer for said tool happens to create folders called "bin" and "lib", and add both to PATH (or add an App Paths entry in the Registry so that this happens automatically when the application is run), so what... --tml |