Help! Any insight on my four problems with completing the installation of gnome? I'm getting many compilation errors -- conflicting and missing declarations -- not just dependency issues. 1. gedit: I get down to compiling gedit-languages-manager.o and the following is reported: gedit-languages-manager.c:115: error: conflicting types for 'gdk_color_to_string' /opt/local/include/gtk-2.0/gdk/gdkcolor.h:137: error: previous declaration of 'gdk_color_to_string' was here make[4]: *** [gedit-languages-manager.lo] Error 1 I believe that conflict with gdkcolor.h is the result of my having installed gnucash first and then going on to gnome. I tried upgrading gtk2, but port didn't seem to think it was necessary. 2. gnome-applets -- an undeclared variable on 'make all' -- what's missing? Command output: applet.c:1036: error: 'applet' undeclared (first use in this function) applet.c: At top level: applet.c:1062: error: parse error before '*' token applet.c: In function 'gnome_volume_applet_refresh': applet.c:1075: error: 'applet' undeclared (first use in this function) applet.c:1100: error: 'force_refresh' undeclared (first use in this function) applet.c: In function 'cb_check': applet.c:1160: error: parse error before ')' token applet.c:1160: error: parse error before ')' token applet.c: In function 'cb_gconf': applet.c:1175: error: 'applet' undeclared (first use in this function) applet.c: In function 'cb_prefs_destroy': applet.c:1273: error: parse error before ')' token applet.c:1273: error: parse error before ')' token applet.c: In function 'cb_verb': applet.c:1281: error: 'applet' undeclared (first use in this function) applet.c:1281: error: parse error before ')' token applet.c:1281: error: parse error before ')' token applet.c: In function 'cb_ui_event': applet.c:1357: error: 'applet' undeclared (first use in this function) applet.c:1357: error: parse error before ')' token applet.c:1357: error: parse error before ')' token applet.c: In function 'cb_theme_change': applet.c:1377: error: 'applet' undeclared (first use in this function) applet.c:1377: error: parse error before ')' token applet.c:1377: error: parse error before ')' token make[3]: *** [applet.o] Error 1 3. seahorse fails compiling seahorse-secure-memory.o /usr/bin/ld: multiple definitions of symbol _g_free /opt/local/lib/libglib-2.0.dylib(gmem.o) definition of _g_free ../../libseahorse/libseahorse.a(seahorse-secure-memory.o) definition of _g_free in section (__TEXT,__text) /usr/bin/ld: multiple definitions of symbol _g_malloc /opt/local/lib/libglib-2.0.dylib(gmem.o) definition of _g_malloc ../../libseahorse/libseahorse.a(seahorse-secure-memory.o) definition of _g_malloc in section (__TEXT,__text) /usr/bin/ld: multiple definitions of symbol _g_malloc0 /opt/local/lib/libglib-2.0.dylib(gmem.o) definition of _g_malloc0 ../../libseahorse/libseahorse.a(seahorse-secure-memory.o) definition of _g_malloc0 in section (__TEXT,__text) /usr/bin/ld: multiple definitions of symbol _g_realloc /opt/local/lib/libglib-2.0.dylib(gmem.o) definition of _g_realloc ../../libseahorse/libseahorse.a(seahorse-secure-memory.o) definition of _g_realloc in section (__TEXT,__text) collect2: ld returned 1 exit status 4. This one may be covered by ticket #10880 gnome-desktop-suite: gedit fails to compile (see below), and I get this: Error: The following dependencies failed to build: gedit gnome-applets seahorse Error: Status 1 encountered during processing. I looked for the package ports file, thinking I could try to build without those, but didn't find it. Maybe all my problems are the result of installing gnucash first? Thanks __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi, Barry Schiffman wrote:
1. gedit:
I get down to compiling gedit-languages-manager.o and the following is reported:
gedit-languages-manager.c:115: error: conflicting types for 'gdk_color_to_string'
/opt/local/include/gtk-2.0/gdk/gdkcolor.h:137: error: previous declaration of 'gdk_color_to_string' was here
I get this one too, no idea how to go around.
2. gnome-applets -- an undeclared variable on 'make all' -- what's missing?
The volume control applet cannot be compiled for some reason (did not have time to actually find the reason), I solved this temporarily by not compiling the said applet (I changed into the working directory, I replaced the makefile of the offending applet with a dummy one, and I re-issued the install command which completed successfully).
3. seahorse fails compiling seahorse-secure-memory.o
I have seahorse @1.0_1 installed but I have not had a chance to upgrade this one.
4. This one may be covered by ticket #10880 gnome-desktop-suite:
gedit fails to compile (see below), and I get this:
Error: The following dependencies failed to build: gedit gnome-applets seahorse
This is caused by the above three failures. What amazes me is that every time GNOME is being updated a whole bunch of problems appear. For one thing dependencies need to be recompiled quite often (doable by hand only!). Some compilation errors are also invariably present. I am wondering why do I need to upgrade a stable GNOME installation to what always turns out to be an unstable GNOME, not ready for prime time. I would not do that personally, except that the port system asks me to do so. At least in this respect a branching into stable and development is sorely needed, as is a dependency rebuild utility. Stefan
On Oct 24, 2007, at 13:19, Stefan Bruda wrote:
What amazes me is that every time GNOME is being updated a whole bunch of problems appear. For one thing dependencies need to be recompiled quite often (doable by hand only!). Some compilation errors are also invariably present. I am wondering why do I need to upgrade a stable GNOME installation to what always turns out to be an unstable GNOME, not ready for prime time. I would not do that personally, except that the port system asks me to do so. At least in this respect a branching into stable and development is sorely needed, as is a dependency rebuild utility.
Nobody forces you to upgrade any port, or any other software on your machine, for that matter. You can choose to upgrade, or not. That being said, new versions should be better than old ones. If you find problems with new versions, please file tickets. How would splitting the ports tree into stable and unstable help? Specifically, if we declare our current ports tree "unstable", by what mechanism does software get to the "stable" branch? Who decides what is stable and when? We currently have no information about how many of our ports even build currently, and of course that varies by OS and platform.
At 20:01 -0500 on 2007-10-24 Ryan Schmidt wrote:
Nobody forces you to upgrade any port, or any other software on your machine, for that matter. You can choose to upgrade, or not.
Yes it does: An automatic `port upgrade outdated' will upgrade everything. Should I then sit down every time and decide what I want to upgrade and what I don't? On what should I base my decision? There is no keyword to help me out. I was under the impression that Macports is a production system, so it should upgrade to a usable configuration automatically--if not all the time at least most of the time.
That being said, new versions should be better than old ones.
Precisely. GNOME in particular is consistently problematic at first when it is upgraded and it should not be.
If you find problems with new versions, please file tickets.
Of course, but in the meantime I would like to keep a usable installation. If I have a test machine (which I don't) I would be more than happy to live on the edge and report bugs; however whenever I am upgrading my production machine I like to have things mostly working--the DE being one important piece, I like to have it working all the time.
How would splitting the ports tree into stable and unstable help? Specifically, if we declare our current ports tree "unstable", by what mechanism does software get to the "stable" branch? Who decides what is stable and when? We currently have no information about how many of our ports even build currently, and of course that varies by OS and platform.
That's an excellent point. I guess the maintainer could decide on the matter. What I would like to see is actually versioning (Gentoo style), tagged with a stable/unstable keywords. If I want to keep a stable system, I can keep within the stable versions; if I want to live on the edge, I can go to development; if I am tired of living on the edge I can reset my keyword and re-upgrade (port upgrade will then need to be capable of downgrading too); if I want to live in the edge only for a portion of the tree, then I should be able to "unmask" ports individually. Right now I don't even know what I did when the system broke--there are no longs so I cannot go back in time even manually unless I write down the list of ports being upgraded before I issue the upgrade command. But then I might be the only one who could use this, so do not take my comments more seriously than they are worth. Cheers, Stefan -- If it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic. --Lewis Carroll, Through the Looking-Glass
On Oct 25, 2007, at 9:29 AM, Stefan Bruda wrote:
That's an excellent point. I guess the maintainer could decide on the matter. What I would like to see is actually versioning (Gentoo style), tagged with a stable/unstable keywords. If I want to keep a stable system, I can keep within the stable versions; if I want to live on the edge, I can go to development; if I am tired of living on the edge I can reset my keyword and re-upgrade (port upgrade will then need to be capable of downgrading too); if I want to live in the edge only for a portion of the tree, then I should be able to "unmask" ports individually.
Macports is run entirely by volunteers, none of whom get paid to do it. If you want some new functionality, the best way to get it is to work on it and offer it to the community. If we had a test-build system of some sort set up, it would be possible to at least tag ports as building successfully or not.... (hint hint).
Right now I don't even know what I did when the system broke--there are no longs so I cannot go back in time even manually unless I write down the list of ports being upgraded before I issue the upgrade command.
You could upgrade with -dv and redirect the output to a file so you could go back and look at it later. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
Citando Stefan Bruda :
At 20:01 -0500 on 2007-10-24 Ryan Schmidt wrote:
Nobody forces you to upgrade any port, or any other software on your machine, for that matter. You can choose to upgrade, or not.
Yes it does: An automatic `port upgrade outdated' will upgrade everything.
[...]
If you find problems with new versions, please file tickets.
Of course, but in the meantime I would like to keep a usable installation. If I have a test machine (which I don't) I would be more than happy to live on the edge and report bugs; however whenever I am upgrading my production machine I like to have things mostly working--the DE being one important piece, I like to have it working all the time.
Be happy then because when you upgrade a port, macports cleverly keeps the previous version (as inactive ports), so you can roll back to the version that was working so well for you and that you were forced to upgrade by a dictatorial automatic port upgrade outdated. Emmanuel
Hi, Daniel J. Luke wrote:
Macports is run entirely by volunteers, none of whom get paid to do it.
I know, of course; I am myself involved in free software.
If you want some new functionality, the best way to get it is to work on it and offer it to the community.
As soon as I have the time to learn TCL and the innards of the Macports system (I am working on it). Still, I hope you don't mind if I comment on features and whatnot--if only developers can comment on these then please say so. By the way, if I offended somebody I do apologize, as this was not my intention whatsoever.
If we had a test-build system of some sort set up, it would be possible to at least tag ports as building successfully or not.... (hint hint).
Unfortunately I have only one Mac OS machine, which is not permanently on line (it is my day to day laptop).
You could upgrade with -dv and redirect the output to a file so you could go back and look at it later.
That's an excellent suggestion, thank you very much. Stefan
On Oct 25, 2007, at 12:40 PM, Stefan Bruda wrote:
If you want some new functionality, the best way to get it is to work on it and offer it to the community.
As soon as I have the time to learn TCL and the innards of the Macports system (I am working on it).
That's great to hear!
Still, I hope you don't mind if I comment on features and whatnot--if only developers can comment on these then please say so.
No, I just wanted to make sure you understood that there wasn't an army of programmers waiting to implement your idea :)
By the way, if I offended somebody I do apologize, as this was not my intention whatsoever.
I understand, I also apologize if anyone found my response offensive. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
participants (5)
-
Barry Schiffman
-
Daniel J. Luke
-
Emmanuel Hainry
-
Ryan Schmidt
-
Stefan Bruda