Date: Mon, 26 Sep 2005 11:36:05 +0300 From: Panagiotis Astithas <past@ebs.gr> To: Mark Hobden <markhobden@gmail.com> Cc: freebsd-eclipse@freebsd.org Subject: Re: Eclipse 3.1_2 window problems Message-ID: <4337B2F5.3050005@ebs.gr> In-Reply-To: <c57a7630050925042358c6b12a@mail.gmail.com> References: <1127383357.51404.26.camel@tos.teleplan.no> <c57a76300509220750d1e9eb6@mail.gmail.com> <4333CC65.90008@ebs.gr> <c57a7630050924155756ff1206@mail.gmail.com> <1127638645.22892.2.camel@localhost> <c57a763005092503495c31c327@mail.gmail.com> <1127646616.22892.6.camel@localhost> <c57a7630050925042358c6b12a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Hobden wrote: > On 9/25/05, Vladimir Grebenschikov <vova@fbsd.ru> wrote: > >>% ls -l /usr/X11R6/lib/libgtk*.0 >>-rwxr-xr-x 1 root wheel 3040701 Sep 19 14:05 /usr/X11R6/lib/libgtk-x11-2.0.so.0 >>-rwxr-xr-x 1 root wheel 1767607 Sep 11 17:52 /usr/X11R6/lib/libgtkhtml-2.so.0 >>-rwxr-xr-x 1 root wheel 429268 Sep 11 17:57 /usr/X11R6/lib/libgtksourceview-1.0.so.0 >>-rwxr-xr-x 1 root wheel 23521 Sep 13 23:20 /usr/X11R6/lib/libgtkspell.so.0 >>% >> >>But I have gnome-2.12 system, actually problems start after upgrading to >>2.12. > > > So thats why just running -clean or deleting the .eclipse files worked > for you and not for me. I hope restoring the > manualpatch-plugins-swt-gtk-os_custom.h file does not break it for > users running the new test port of gtk/gnome do you still have files > matching: > % ls -l /usr/X11R6/lib/libgtk*.so The reason this patch was removed was to avoid treating FreeBSD differently than other Unix systems, at the suggestion of an IBM engineer. This is was he said: "I intend to apply the patches to the launcher and SWT, but I have one question. I've been worried about the use of "libgtk-x11-2.0.so.0" vs "libgtk-x11-2.0.so" on *BSD vs Linux. For shared libraries, the first number is the major version number, and an unversioned .so link is supposed to point at the current development version (it's what -l uses). We can't dlopen the .so on every platform because doesn't always exist. Under many Linux distributions, the .so symbolic link only exists in the -devel package. I have heard that the library version weirdness on FreeBSD is due to a libtool bug, and is fixed by an "ltverhack" script at some point, but I have not been able to verify this." In my tests I concluded that it was unnecessary and I received no responses or complaints when I asked for testers. I'm glad that bringing it back is a satisfactory solution to this problem, and I don't expect any trouble from it, but I wonder whether there is some dlopen flag that should be used instead. Cheers, Panagiotis
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4337B2F5.3050005>