Re: [CentOS] e-sata
Les Mikesell wrote: > cen...@911networks.com wrote: > >> Hi, >> >> Does anybody has any experience with e-sata on CentOS5.2? >> >> - How fast is it? Same as an internal sata? >> - Does it support sata-2? >> - Does it "hot-plug" like a USB? >> > > The 'E' just means the connector comes out the back. Otherwise it is > the same as internal with the same options that depend on the controller > model and driver. Most, but not all SATA controllers support hot-plug > but I think it needs to be done at the drive level, not the cable to the > case so the connectors can enforce the right order of connections on the > power and data side. > its also a slightly different connector, they are keyed differently so you can't use a internal SATA cable in extenral eSATA jack.eSATA spec allows longer wiring, and requires better shielding. ALL sata connectors physically have hotswap capability to support raid backplanes and such (primarily, longer ground pins), but as you said, there's software issues in recognizing new devices and enumerating them and bringing up their dev nodes. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] e-sata
Hi, On Sun, Jan 25, 2009 at 17:02, wrote: > Does anybody has any experience with e-sata on CentOS5.2? Yes. > - How fast is it? Same as an internal sata? Same as internal. Just the connector is different. > - Does it support sata-2? > - Does it "hot-plug" like a USB? Depends on the adapter you get. First time I got an Adaptec eSATA II RAID 1225SA and it turns out that, even though they use a standard Silicon Image 3132 (IIRC) that is supported by the sata_sil24 native driver, they ship it with a non-default PCI ID, so the default kernel in CentOS 5 does not recognize it. I opened a bug for it and I got the patch to include that PCI ID in CentOS-plus kernel, so if you use that kernel the adapter will work. Anyway, I would stay away of it if possible. http://www.adaptec.com/en-US/support/raid/sataii/AAR-1225SA/ Second time around I got one from StarTech.com, it also uses the sata_sil24 native driver, and this one works out of the box. I just had a small glitch to have it recognized by the server the first time around, which was fixed by moving it to another PCIe slot (not sure why it did not work on the first one I tried). I can recommend this one: http://www.startech.com/item/PEXESATA2-2-Port-PCI-Express-eSATA-Controller-Card.aspx Both work with SATA II (3Gbps) and both support "hot-plug", only in some cases you may need to force scanning (with a command such as "echo 1 >/sys/class/scsi_host/hostX/scan"), I'm not sure if you have to do that always or not. Here some information on Linux SATA drivers, very useful: http://linuxmafia.com/faq/Hardware/sata.html Stay away from those that need proprietary drivers. I still would like to find an adapter that works with the Linux ahci driver, since that seems to be the best one, at least from information in that web page, but so far no luck finding them... HTH, Filipe ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Problem compiling cairo-dock under CentOS 5.2
Hi, On Sun, Jan 25, 2009 at 17:14, Marko Vojinovic wrote: > * update glib2 and possibly glibc and its dependencies? Bad idea. If you do that, what you will have at the end will no longer be CentOS, and if you break it, you got to keep the pieces. > * temper with the cairo-dock source to remove references to new functions and > make it compatible with glib2 v2.12 (this is possible, but not easy)? Agreed, possible, but I think it's going to be really hard. > * wait for CentOS 5.3 hoping that it has more recent glib2? CentOS 5.3 (or any other 5.x) should not introduce any major upgrades to glibc or glib2, although minor updates with mainly bug fixes are expected, it should not bump to another version just like that. > * give up? Or try it under Fedora. If you want cutting-edge software, that is what you should be looking for anyway. Or yet, you could try to get version 1.x of cairo-dock to build under CentOS, as that one is more likely to be built than the newer 2.x. HTH, Filipe ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] e-sata
cen...@911networks.com wrote: > Hi, > > Does anybody has any experience with e-sata on CentOS5.2? > > - How fast is it? Same as an internal sata? > - Does it support sata-2? > - Does it "hot-plug" like a USB? The 'E' just means the connector comes out the back. Otherwise it is the same as internal with the same options that depend on the controller model and driver. Most, but not all SATA controllers support hot-plug but I think it needs to be done at the drive level, not the cable to the case so the connectors can enforce the right order of connections on the power and data side. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Problem compiling cairo-dock under CentOS 5.2
William L. Maltby wrote: > On Sun, 2009-01-25 at 23:14 +0100, Marko Vojinovic wrote: >> > >> To partially answer my own question, it appears that g_timeout_add_seconds >> was >> introduced in glib2 library, starting from version 2.14, while my current >> CentOS installation has version 2.12.3-2. Now, it turns out that glib2 >> depends on glibc, gamin and libselinux, my current versions being 2.5.24, >> 0.1.7-8 and 1.33.4-5 respectively. >> >> So, to reformulate the question: is there a clean way to upgrade glib2 from >> 2.12 to 2.14 without having to upgrade glibc and friends (and glibc has *a >> lot* of friends installed on the system :-) ...). >> >> This is a desktop machine which is not quite important for production etc, >> so >> I wouldn't mind customizing it if it isn't too much hassle. >> >> I am open to suggestions on what to do --- >> >> * update glib2 and possibly glibc and its dependencies? >> * temper with the cairo-dock source to remove references to new functions >> and >> make it compatible with glib2 v2.12 (this is possible, but not easy)? >> * wait for CentOS 5.3 hoping that it has more recent glib2? >> * give up? >> >> Appreciate any help! > > If you can wait, some recent posts in other threads indficate that glibc > is to be upgraded in 5.3 (which RH has recently released ?). So CentOS > should offer the updates in around 5 weeks or so. > Glib2 hasn't been updated in 5.3 - it's still at version 2.12.3-2 as per the original release. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Problem compiling cairo-dock under CentOS 5.2
On Sun, 2009-01-25 at 23:14 +0100, Marko Vojinovic wrote: > > To partially answer my own question, it appears that g_timeout_add_seconds > was > introduced in glib2 library, starting from version 2.14, while my current > CentOS installation has version 2.12.3-2. Now, it turns out that glib2 > depends on glibc, gamin and libselinux, my current versions being 2.5.24, > 0.1.7-8 and 1.33.4-5 respectively. > > So, to reformulate the question: is there a clean way to upgrade glib2 from > 2.12 to 2.14 without having to upgrade glibc and friends (and glibc has *a > lot* of friends installed on the system :-) ...). > > This is a desktop machine which is not quite important for production etc, so > I wouldn't mind customizing it if it isn't too much hassle. > > I am open to suggestions on what to do --- > > * update glib2 and possibly glibc and its dependencies? > * temper with the cairo-dock source to remove references to new functions and > make it compatible with glib2 v2.12 (this is possible, but not easy)? > * wait for CentOS 5.3 hoping that it has more recent glib2? > * give up? > > Appreciate any help! If you can wait, some recent posts in other threads indficate that glibc is to be upgraded in 5.3 (which RH has recently released ?). So CentOS should offer the updates in around 5 weeks or so. I don't have enough knowledge to offer anything more. Hopefully some others can help you sooner. > > Best, :-) > Marko > HTH -- Bill ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] e-sata
Marko A. Jennings wrote: > On Sun, January 25, 2009 5:02 pm, cen...@911networks.com wrote: > >> Does anybody has any experience with e-sata on CentOS5.2? >> >> - How fast is it? Same as an internal sata? >> - Does it support sata-2? >> - Does it "hot-plug" like a USB? >> > > I use one ExpressCard eSATA II controller with a laptop under CentOS 5. > The controller requires reboot in order to be recognized (at least I don't > know a way to make it work any other way), but the disks are hot-pluggable > just like with USB. No idea how the speed compares to internal SATA. > speed is identical, signalling wise, its SATA-2 (3Gbps) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] e-sata
On Sun, January 25, 2009 5:02 pm, cen...@911networks.com wrote: > Does anybody has any experience with e-sata on CentOS5.2? > > - How fast is it? Same as an internal sata? > - Does it support sata-2? > - Does it "hot-plug" like a USB? I use one ExpressCard eSATA II controller with a laptop under CentOS 5. The controller requires reboot in order to be recognized (at least I don't know a way to make it work any other way), but the disks are hot-pluggable just like with USB. No idea how the speed compares to internal SATA. Marko ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] e-sata
Hi, Does anybody has any experience with e-sata on CentOS5.2? - How fast is it? Same as an internal sata? - Does it support sata-2? - Does it "hot-plug" like a USB? -- Thanks http://www.911networks.com When the network has to work ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Problem compiling cairo-dock under CentOS 5.2
On Sunday 25 January 2009 17:10, Marko Vojinovic wrote: > I am trying to compile cairo-dock from source (failing to find an existing > package for CentOS). I believe all dependencies are satisfied, but while > doing "make", at some point it says (I can provide the full make output if > it's needed): > [snip] > /home/vmarko/cairo/cairo-dock-2.0.0-beta1/src/cairo-dock.c:724: undefined > reference to `g_timeout_add_seconds' To partially answer my own question, it appears that g_timeout_add_seconds was introduced in glib2 library, starting from version 2.14, while my current CentOS installation has version 2.12.3-2. Now, it turns out that glib2 depends on glibc, gamin and libselinux, my current versions being 2.5.24, 0.1.7-8 and 1.33.4-5 respectively. So, to reformulate the question: is there a clean way to upgrade glib2 from 2.12 to 2.14 without having to upgrade glibc and friends (and glibc has *a lot* of friends installed on the system :-) ...). This is a desktop machine which is not quite important for production etc, so I wouldn't mind customizing it if it isn't too much hassle. I am open to suggestions on what to do --- * update glib2 and possibly glibc and its dependencies? * temper with the cairo-dock source to remove references to new functions and make it compatible with glib2 v2.12 (this is possible, but not easy)? * wait for CentOS 5.3 hoping that it has more recent glib2? * give up? Appreciate any help! Best, :-) Marko ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] can't install rrdtool, problems with dependancies
On Sun, Jan 25, 2009 at 02:18:14PM -0500, Jim Perrin wrote: > Yes. I know it works as well. Since others had taken to smacking the > OP around immediately (even thought it was justified) I felt no need > to smack him again. By shifting the blame/reason/whatever to something > other than his system, I felt I might be able to draw out more > information to help. Consider it the 'good cop' portion of the > interrogation. :-) Now look, we give you those rubber hoses for a reason! :) -- ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] can't install rrdtool, problems with dependancies
On Sat, Jan 24, 2009 at 10:31 AM, Kai Schaetzl wrote: > Jim Perrin wrote on Sat, 24 Jan 2009 08:47:43 -0500: > >> or packaging >> oversite in rpmforge > > no, I know it works. Yes. I know it works as well. Since others had taken to smacking the OP around immediately (even thought it was justified) I felt no need to smack him again. By shifting the blame/reason/whatever to something other than his system, I felt I might be able to draw out more information to help. Consider it the 'good cop' portion of the interrogation. :-) -- During times of universal deceit, telling the truth becomes a revolutionary act. George Orwell ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT? File order on CentOS/Samba server -- SOLVED (kind of...)
>>> Well, I did try to compile it but make fails on all the Linux computers >>> I have access to. They all run CentOS 5.2. It would be nice to have a >>> .rpm... I am a sysadmin, not a programmer, I am not able to solve most >>> compile errors. >>> > > I will have a hack at compiling it later on because I am very > interested in it. If I manage to get it rolling I will send out a mail > to you and update the thread here on the list. I have had great > success with the clamav vfs module. > > That would be GREAT! Thank you! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT? File order on CentOS/Samba server
>> Sounds like a bug in the program. Maybe it runs a separate instance for >> each page in that mode and doesn't release any memory until it is all >> finished. On something smaller or less complex it might not make much >> difference, but if the memory use pushes into swap it will take much longer. >> >> Yes, that's what it seems to me. As I said before, it starts processing swiftly but soon each new page takes longer and longer until it crawls. CPU time reaches 98% and the memory footprint keeps increasing untill the end of the process. This happens even on a standalone Windows workstation, not only over the network. I can report this to Adobe but I don't have too much hope about the attention such a large company is going to give to such an issue... >> By the way, yet another really-contorted workaround would be to run >> VMware server or virtualbox (both free) on the centos box with a windows >> guest to get a reliable NTFS network drive. If you have resources to >> spare on this server you could even run distiller there so you could >> shut down the workstations as soon as the final run starts. I thought of doing that but it really is not realistic at the moment in my environment. It is overkill. It would be much easier to put a small FAT32-formated partition on the server just for that purpose. The PS files are not kept. After processing they are discarded, only the resulting PDF is used and archived. For now I will stick with a EXT3 partition with dir_index off and use rundirex like we always did. It works well this way: 3 to 4 minutes to render a complete publication. Thank you for your tips. Even if I don't use them now, the information stays. Maybe it will be needed one of these days. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT? File order on CentOS/Samba server
Miguel Medalha wrote: >> Filipe, it is possible it is taking so long to do a "sort" because when >> doing it, it caches it on the client side of Distiller also + does it on the >> Samba Server to. IE; Sorts on Both Sides. >> >> >> > I tried it, several times, on a standalone Windows workstation and the > same happens. > I am not saying that the sorting takes too much time; the whole process > takes too much time. > > And please note that it also happens with the runfilex.ps code provided > by Adobe, which does not sort but instead presents Distiller with a list > of files to process, instead of letting it rely on the dir order. > Sorting is not the problem here. Sounds like a bug in the program. Maybe it runs a separate instance for each page in that mode and doesn't release any memory until it is all finished. On something smaller or less complex it might not make much difference, but if the memory use pushes into swap it will take much longer. By the way, yet another really-contorted workaround would be to run VMware server or virtualbox (both free) on the centos box with a windows guest to get a reliable NTFS network drive. If you have resources to spare on this server you could even run distiller there so you could shut down the workstations as soon as the final run starts. It isn't the most efficient way to do things, but I've had some running that way for years with no unexpected problems. The only inconvenience is that at least in the VMware server case on centos 5, whenever you update the kernel and reboot, you have to run a script that recompiles the vmware module before the guest will run. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT? File order on CentOS/Samba server
> Filipe, it is possible it is taking so long to do a "sort" because when > doing it, it caches it on the client side of Distiller also + does it on the > Samba Server to. IE; Sorts on Both Sides. > > > I tried it, several times, on a standalone Windows workstation and the same happens. I am not saying that the sorting takes too much time; the whole process takes too much time. And please note that it also happens with the runfilex.ps code provided by Adobe, which does not sort but instead presents Distiller with a list of files to process, instead of letting it rely on the dir order. Sorting is not the problem here. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT? File order on CentOS/Samba server
> -Original Message- > From: centos-boun...@centos.org > [mailto:centos-boun...@centos.org] On Behalf Of Filipe Brandenburger > Sent: Saturday, January 24, 2009 8:13 PM > To: CentOS mailing list > Subject: Re: [CentOS] OT? File order on CentOS/Samba server > > Oi Miguel, > > On Sat, Jan 24, 2009 at 15:24, Miguel Medalha > wrote: > > Thank you for caring to look for and post the code. > > No problem! Glad to help. > > > At first I became very excited about it. But then I tried it... > > > > It does work. The problem is that it suffers from the same > illness as > > runfilex does: it takes forever. The process starts very > swiftly but each > > new processed page takes longer and longer until it all > slows to a crawl. > > Worse yet, Distiller goes on to use enormous (> 90%) > amounts of CPU time. > > > > I just measured the process as folllows, for the same set of files, > > corresponding to a 32 page publication in A3 format: > > > > rundirex: 3m42s > > runfilex: 1h29m54s > > Wikipedia code: 1h14m55s > > That is really weird, since it's only sorting a list before starting > the processing, but once the processing is started, it does exactly > the same in both cases (the only difference is that in one case > "filenameforall" is used and in the other case "forall" is used over > an array with the sorted list of files). > > Do you have a support contract with Adobe? If you do, I think you > should bring up this issue with them and try to figure out where the > huge performance difference is coming from, since it should not. > > > I suppose I will end up creating a FAT32 partition on the > server just for > > this purpose. > > and: > > > I just turned dir_index OFF with tune2fs. Now the directory > order is the > > same as the inode order. This makes the order of files > predictable and > > in fact turns out to solve my problem. > > > > With dir_index turned OFF on that filesystem, when a copy is made to > > another directory (even from Windows on a Samba share) the > > alphanumeric order is preserved. I will just ask the workstation > > operators to copy the PS files to a new folder when they are all > > ready. Distiller is watching that folder and will process > the files in the > > normal way, using the rundirex file. > > I don't think turning dir_index off will make the order as predictable > as you want it. It may be a good enough work around for now, but it > might lead to strange problems in the future that you may end up > having to deal with again. > > I would really advise you to investigate why when you list the files > in the order you want in the input file it takes so long. -- Filipe, it is possible it is taking so long to do a "sort" because when doing it, it caches it on the client side of Distiller also + does it on the Samba Server to. IE; Sorts on Both Sides. I have had this happen in .Net. When doing a sort in .Net the default is to sort on the client and the server. JohnStanley ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT? File order on CentOS/Samba server
> That is really weird, since it's only sorting a list before starting > the processing, but once the processing is started, it does exactly > the same in both cases (the only difference is that in one case > "filenameforall" is used and in the other case "forall" is used over > an array with the sorted list of files). > > Weird indeed. But repeatable and confirmed again and again. It doesn't happen only over the network. It happens at the local level too, with Distiller and all files on the same workstation. > I don't think turning dir_index off will make the order as predictable > as you want it. It may be a good enough work around for now, but it > might lead to strange problems in the future that you may end up > having to deal with again. > > I don't have a choice right now. Newspapers don't wait, you know :) > I would really advise you to investigate why when you list the files > in the order you want in the input file it takes so long. > > I will certainly investigate it. I am a curious mind, for the worse and for the better :) > Boa Sorte! > Agradeço. Saudações! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Problem compiling cairo-dock under CentOS 5.2
I am trying to compile cairo-dock from source (failing to find an existing package for CentOS). I believe all dependencies are satisfied, but while doing "make", at some point it says (I can provide the full make output if it's needed): gcc -g -O2 -o cairo-dock -Wl,--export-dynamic cairo_dock-cairo-dock-callbacks.o cairo_dock-cairo-dock.o cairo_dock-cairo-dock-dbus.o cairo_dock-cairo-dock-draw.o cairo_dock-cairo-dock-config.o cairo_dock-cairo-dock-load.o cairo_dock-cairo-dock-icons.o cairo_dock-cairo-dock-applications-manager.o cairo_dock-cairo-dock-menu.o cairo_dock-cairo-dock-modules.o cairo_dock-cairo-dock-launcher-factory.o cairo_dock-cairo-dock-application-factory.o cairo_dock-cairo-dock-applet-factory.o cairo_dock-cairo-dock-separator-factory.o cairo_dock-cairo-dock-desktop-file-factory.o cairo_dock-cairo-dock-keyfile-utilities.o cairo_dock-cairo-dock-dock-factory.o cairo_dock-cairo-dock-animations.o cairo_dock-cairo-dock-themes-manager.o cairo_dock-cairo-dock-notifications.o cairo_dock-cairo-dock-dialogs.o cairo_dock-cairo-dock-surface-factory.o cairo_dock-cairo-dock-renderer-manager.o cairo_dock-cairo-dock-default-view.o cairo_dock-cairo-dock-applet-facility.o cairo_dock-cairo-dock-file-manager.o cairo_dock-eggaccelerators.o cairo_dock-cairo-dock-keybinder.o cairo_dock-cairo-dock-desklet.o cairo_dock-cairo-dock-log.o cairo_dock-cairo-dock-X-utilities.o cairo_dock-cairo-dock-gauge.o cairo_dock-cairo-dock-dock-manager.o cairo_dock-cairo-dock-class-manager.o cairo_dock-cairo-dock-emblem.o cairo_dock-cairo-dock-flying-container.o cairo_dock-cairo-dock-graph.o cairo_dock-cairo-dock-draw-opengl.o cairo_dock-cairo-dock-particle-system.o cairo_dock-cairo-dock-gui-factory.o cairo_dock-cairo-dock-gui-callbacks.o cairo_dock-cairo-dock-gui-manager.o cairo_dock-cairo-dock-internal-position.o cairo_dock-cairo-dock-internal-accessibility.o cairo_dock-cairo-dock-internal-system.o cairo_dock-cairo-dock-internal-taskbar.o cairo_dock-cairo-dock-internal-hidden-dock.o cairo_dock-cairo-dock-internal-dialogs.o cairo_dock-cairo-dock-internal-indicators.o cairo_dock-cairo-dock-internal-views.o cairo_dock-cairo-dock-internal-labels.o cairo_dock-cairo-dock-internal-desklets.o cairo_dock-cairo-dock-internal-background.o cairo_dock-cairo-dock-internal-icons.o -pthread -Wl,--export-dynamic -lXtst -lXcomposite -lXfixes -lXinerama -L/lib -lgthread-2.0 -lrsvg-2 -ldbus-glib-1 -ldbus-1 -lxml2 -lz -lgtkglext-x11-1.0 -lgdkglext-x11-1.0 -lGLU -lGL -lXmu -lXt -lSM -lICE -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 cairo_dock-cairo-dock.o: In function `main': /home/vmarko/cairo/cairo-dock-2.0.0-beta1/src/cairo-dock.c:724: undefined reference to `g_timeout_add_seconds' cairo_dock-cairo-dock-applications-manager.o: In function `cairo_dock_get_current_applis_list': /home/vmarko/cairo/cairo-dock-2.0.0-beta1/src/cairo-dock-applications-manager.c:1389: undefined reference to `g_hash_table_get_values' cairo_dock-cairo-dock-menu.o: In function `cairo_dock_notification_build_menu': /home/vmarko/cairo/cairo-dock-2.0.0-beta1/src/cairo-dock-menu.c:1081: undefined reference to `gtk_widget_set_tooltip_text' /home/vmarko/cairo/cairo-dock-2.0.0-beta1/src/cairo-dock-menu.c:1318: undefined reference to `gtk_widget_set_tooltip_text' /home/vmarko/cairo/cairo-dock-2.0.0-beta1/src/cairo-dock-menu.c:1143: undefined reference to `gtk_widget_set_tooltip_text' cairo_dock-cairo-dock-applet-facility.o: In function `_cairo_dock_restart_timer_with_frequency': /home/vmarko/cairo/cairo-dock-2.0.0-beta1/src/cairo-dock-applet-facility.c:523: undefined reference to `g_timeout_add_seconds' cairo_dock-cairo-dock-applet-facility.o: In function `_cairo_dock_check_for_redraw': /home/vmarko/cairo/cairo-dock-2.0.0-beta1/src/cairo-dock-applet-facility.c:392: undefined reference to `g_timeout_add_seconds' cairo_dock-cairo-dock-applet-facility.o: In function `cairo_dock_launch_measure': /home/vmarko/cairo/cairo-dock-2.0.0-beta1/src/cairo-dock-applet-facility.c:443: undefined reference to `g_timeout_add_seconds' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libgdkglext-x11-1.0.so: undefined reference to `pango_x_font_subfont_xlfd' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libgdkglext-x11-1.0.so: undefined reference to `pango_x_font_map_for_display' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libgdkglext-x11-1.0.so: undefined reference to `pango_x_font_cache_unload' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libgdkglext-x11-1.0.so: undefined reference to `pango_x_find_first_subfont' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libgdkglext-x11-1.0.so: undefined reference to `pango_x_font_map_get_font_cache' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libgdkglext-x11-1.0.so: undefined reference to `pango_x_font_cache_load' collect2: ld returned 1 exit status make[3]: *** [cairo-dock] Error 1 make[3]: Leaving direct
