GNOME Bugzilla – Bug 547292
Glom Windows installer problems
Last modified: 2008-11-24 17:26:55 UTC
I tried installing Glom on XP, in vmware, from http://ftp.acc.umu.se/pub/GNOME/binaries/win32/glom/1.7/glom-setup-1.7.1.exe I saw this error message: " Your installation of Glom is not complete, because the PostgreSQL libgda provider is not available on your system. This provider is needed to access Postgres database servers. Please report this bug to your vendor, or your system administrator so it can be corrected. "
Was there also another error message, perhaps about missing DLL files? I realized that libpq.dll also depends on ssleay32.dll and libeay32.dll, and if they are not present, then it cannot be loaded, and consequently the postgres libgda provider (which needs libpq.dll) neither. I updated the installer accordingly. Could you please try again?
(In reply to comment #1) > Was there also another error message, perhaps about missing DLL files? No, that was the first UI of any kind after starting Glom from the Start menu. > I realized that libpq.dll also depends on ssleay32.dll and libeay32.dll, and if > they are not present, then it cannot be loaded, and consequently the postgres > libgda provider (which needs libpq.dll) neither. I updated the installer > accordingly. Could you please try again? Thanks. But I get exactly the same result. Could you in future avoid re-uploading the same file. Please use an extra version suffix or something, such as glom-1.7.1-1.exe, documenting how you do that in the README. Please also try to remove the step that asks if I want to install translations. It's not useful to users.
Are you testing this in vmware or something similar? Is there anything you would like me to try in XP, to get more information?
I'm testing (and building, btw) this on a native Windows XP (and also tested it on another native one). You could try if the problem goes away when adding Glom's bin directory (normally C:\Program Files\Glom\bin) to the PATH environment variable. That's just a wild guess, though. Otherwise, the only idea I have so far is to step through the libgda code with a debugger to find out why it does not find the provider. Unfortunately, that's rather time-consuming (you'd also need debug binaries of libgda, and maybe glom. If you are willing to try, then I could provide those). I will try this soon in vmware myself. Perhaps I'll experience the same problem. I removed the components selection step from the installer. It now always installs all translations. Do you think it would be more useful if the user could choose which languages to install?
> I removed the components selection step from the installer. It now always > installs all translations. Do you think it would be more useful if the user > could choose which languages to install? Is this necessary at all? If we install all translations, won't it just use the correct one automatically? I don't want a "Break the application? Yes/No" option.
Yes, it will pick the correct one automatically. Therefore, it isn't necessary to have such a step in the installer. I was just thinking that more users only use a few languages, and don't need all to be installed.
libgda-3.0.2.dll is in C:\Program Files\Glom\bin, but libgda-postgres.dll is in C:\Program Files\Glom\lib\libgda-3.0\providers. how should libgda-3.0.2.dll find libgda-postgres.dll there? By the way, ask me if you need Openismus to get a vmware for you. I forget if you have one already.
That's the way it should be (and the way it works for me). libgda basically uses g_win32_get_installation_directory() which yields the path to the libgda-3.0-2.dll, but without the bin/. Then, it checks for libgda-postgres.dll in lib/libgda-3.0/providers. I have already got vmware from Openismus. Thanks.
I've got the same problem in vmware. I'm not 100% sure what the problem is, but it has something to do with the runtime libraries for Visual Studio 2005 (with which libpq.dll seems to be built). This comes with Service Pack 2 for Windows XP, which is probably why it worked on the computers I tested Glom with. Apparently it is possible to ship that runtime libraries along with the application, though I did not succeed in doing so (the problem remained). Could you please try out whether installing http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en works for you (meaning you can launch glom after having installed this)? If it does, then I could try to make the Glom installer install this automatically (and uninstalling it again, when uninstalling Glom). Other possibilities include using postgresql 8.2.9 (instead of 8.3.3) which does not require that runtime, or building postgresql myself again with mingw.
Yes, that fixes it. If the official PostgreSQL installer doesn't provide this either, they would probably like to know too.
The PostgreSQL installer does provide this, but Glom only installs a few binaries from PostgreSQL; it does not invoke the PostgreSQL installer or something.
Could you try the installer at http://ftp.acc.umu.se/pub/GNOME/binaries/win32/glom/1.7/glom-setup-1.7.1-2.exe? This one contains self-built postgresql binaries (which seems easier and less error-prone than installing that additional runtime). You shouldn't need the vcredist_x86.exe thing with this.
Yes, that installs OK. However, when I try to create a file I get "The document could not be opened." when creating from an example, and creating an empty file just returns me to the initial dialog. Could you try that please. > This one contains self-built postgresql binaries I am a little concerned about that. I imagine that there are several build options, so there's a chance for us to make mistakes.
The problem was to find an available port for the server to self-host on. It uses sockets functions without WinSock having been initialized. I fixed this by initializing it in Glom's main(). I have no idea why this happend in vmware only. There's another problem that .glom files do not get saved correctly, which is why loading a (self-hosted) glom session fails (it still thinks it is an example file). See bug #548988. I'll release another installer when that's fixed. I might have a closer look at this (and maybe write a patch) later myself. Building postgresql against the same C runtime as glom (and libgda) also has other advantages: For example, operation on FILE*s and malloc/free calls only work when issued from the same runtime library. So, if postgresql mallocs something and requires the caller to free it, then bad things will happen if they use a different C runtime. I don't know if postgresql does this, though. Also, postgresql is now linked against the same intl.dll and iconv.dll that GTK+ uses. Before, it had own versions of these, so we would have to ship the same library two times.
> There's another problem that .glom files do not get saved correctly, which is > why loading a (self-hosted) glom session fails (it still thinks it is an > example file). See bug #548988. I'll release another installer when that's > fixed. I might have a closer look at this (and maybe write a patch) later > myself. If you can't fix it for some reason, maybe we can work around it. Well done.
I uploaded ftp://ftp.gnome.org/pub/GNOME/binaries/win32/glom/1.7/glom-setup-1.7.1-3.exe which contains glib and gio from SVN, with the fix for that bug. There is at least one more problem when the computer uses a non-english language, in which case Glom crashes due to an uncaught exception when opening a document. I'll also have a closer look at this.
> There is at least one more problem when the computer uses a non-english language, in which case Glom crashes due to an uncaught exception when opening a document. I'll also have a closer look at this. I can't seem to reproduce this anymore. If somebody wants to try themselves, then change the language in Control Panel->Regional And Language Options, and select something else than English in that "Standards and Formats" combo box, such as German (Germany), and then try creating or opening a Glom document (the Glom user interface should appear (mostly) in German then). Two days ago, this crashed for me. Perhaps it went away with some other change, though I can't imagine a recent one having to do with this.
(In reply to comment #16) > I uploaded > ftp://ftp.gnome.org/pub/GNOME/binaries/win32/glom/1.7/glom-setup-1.7.1-3.exe > which contains glib and gio from SVN, with the fix for that bug. Great. I can now create (and self-host) new documents. (empty and from examples). I had to change to being a "limited" user instead of an admin, and I think I had to restart to actually make that take effect. Otherwise I was getting the error mentioned below, often without the explanatory text. Can we hide that nasty DOS dialog when starting postgres or creating postgres databases? When creating from an example it doesn't seem to even close automatically. And is there any way we can detect whether the user has admin rights, so we can avoid this error dialog. I wonder how postgres checks for it. " Child command failed The command was: 'C:\Program Files\Glom\bin\postgres.exe' -D "C:\Documents and Settings\Murray Cumming\test\glom_postgres_data\data" -p 5434 -i -c hba_file="C:\Documents and Settings\Murray Cumming\test\glom_postgres_data/config/pg_hba.conf" -c ident_file="C:\Documents and Settings\Murray Cumming\test\glom_postgres_data/config/pg_ident.conf" -k "C:\Documents and Settings\Murray Cumming\test\glom_postgres_data" --external_pid_file="C:\Documents and Settings\Murray Cumming\test\glom_postgres_data/pid" Execution of PostgreSQL by a user with administrative permissions is not permitted. The server must be started under an unprivileged user ID to prevent possible system security compromises. See the documentation for more information on how to properly start the server. "
> I had to change to being a "limited" user instead of an admin, and I > think I had to restart to actually make that take effect. I created a second (limited) user for this which did not require a restart. > Otherwise I was getting the error mentioned below, often without the > explanatory text. That explanatory text is the stderr output from postgres.exe. I believe that sometimes we get notified that the child process was closed before having read that data from stderr, but that's just a guess, and it's probably difficult to debug. If Glom checks itself whether the user is an admin or not (see below), then that's perhaps not necessary anymore. > Can we hide that nasty DOS dialog when starting postgres or creating postgres > databases? When creating from an example it doesn't seem to even close > automatically. I don't think that glib's spawn API offers a way to do this, but I will check. We could also try to use the native Windows API directly instead. > And is there any way we can detect whether the user has admin rights, so we can > avoid this error dialog. I wonder how postgres checks for it. Probably there is some Windows API for this. The linux version of Glom already checks for the user being root before Glom even starts. Do you think the Windows version should do the same, or should we allow the user to connect to an existing database as admin? The official postgresql installer for Windows can setup a server on the local computer easy enough for use with Glom (without requiring to create a second user manually, for instance). I think that it is a bit annoying to have to use a limited user account on Windows (at least XP, I don't know Vista) to use Glom, because I normally do everything else with the admin account.
(In reply to comment #19) > > And is there any way we can detect whether the user has admin rights, so we can > > avoid this error dialog. I wonder how postgres checks for it. > > Probably there is some Windows API for this. The linux version of Glom already > checks for the user being root before Glom even starts. Yes, because it's a networked application (sharing .glom files via libepc) and we don't want to take any risks. > Do you think the > Windows version should do the same, or should we allow the user to connect to > an existing database as admin? No, let's prevent that too. But add a comment in the code that as a side-effect we avoid the no-postgres-as-admin problem on Windows. > The official postgresql installer for Windows > can setup a server on the local computer easy enough for use with Glom (without > requiring to create a second user manually, for instance). > > I think that it is a bit annoying to have to use a limited user account on > Windows (at least XP, I don't know Vista) to use Glom, because I normally do > everything else with the admin account. Yeah, but people probably shouldn't do that. It seems acceptable to me as long as we can give meaningful advice in the UI.
Here is a new installer: ftp://ftp.gnome.org/pub/GNOME/binaries/win32/glom/1.7/glom-setup-1.7.1-4.exe I changed the spawn code to use CreateProcess() on Windows, which allows to hide the console window (and also fixes the problem of the missing explanatory error message if postgres can't start). I also copied the pgwin32_is_admin() function from postgresql, to check for the user being admin.
> > Can we hide that nasty DOS dialog when starting postgres or creating postgres > > databases? When creating from an example it doesn't seem to even close > > automatically. > > I don't think that glib's spawn API offers a way to do this, but I will check. This seems like a glib bug. Could you file a bug for that, please, if you agree. I will test the new installer tomorrow. Thanks.
There is already a bug open about this: #509201
So are there any remaining problems with the installer? If not then this bug should be closed.
I don't know of any.