Re: Exportability of EDA industry from North America?

From: Chuck Harris (cf-NO-SPAM-harris_at_erols.com)
Date: 01/16/05 

Date: Sun, 16 Jan 2005 17:51:41 -0500

Hi Ales,

Ales Hvezda wrote:
> Hi,
>
> I usually like spending my free time working on the code rather than
> posting to USENET, but I want to address some of the points from the
> previous poster in this thread.

Thank you, I appreciate your time. I would prefer not to use this
forum for detailed debugging, but since I started this, and have no
interest in performing a hit-and-run tar & feather job, I guess we have
to resolve the problems here in public.

>
> When I first read your response, I was quite curious to see for myself
> if a stock RedHat 9 system really does have so much trouble installing
> gEDA/gaf or running Stuart's gEDA Suite CD installer, so I ran a little
> experiment: I installed stock RedHat 9.0 (Shrike) into a completely new
> system (using vmware):
>
> # cat /etc/issue
> Red Hat Linux release 9 (Shrike)

That is precisely the version I am running.

>
> and then installed gEDA/gaf and the Suite CD. Both installed
> almost out-of-the-box. I followed the INSTALLs and READMEs that
> can be found at:
>
> http://geda.seul.org/download.html

As did I.
>
> The only change I made was to add /usr/local/lib into ld.so.conf
> (and re-ran ldconfig). I have the build typescript to the gEDA/gaf
> build/install if you want to see the evidence.

I have since made that addition to my ld.so.conf as well. It fixes
gschem's problem with dynamic linked libraries. It should be noted that
RedHat never uses /usr/local/lib for its libraries, but your CDROM installs
its dynamic libraries in /usr/local/lib. (Debian on the other hand uses both
locations)

> I'm guessing that those rpms from FreshRPM that you installed, changed
> the standard packages (like gtk+) in a way that they are no longer
> standard or similar to the upstream source packages. See below.

Nope, FreshRPM is an exact configuration of RH9.0 Shrike. They just
add the bug fixes and security updates.
>
> [snip]
>

> Hmmm, on my newly installed RedHat 9.0 system, gtk+ 2.0 is in
> fact called gtk+-2.0, i.e. the following works:
>
> $ pkg-config gtk+-2.0 --cflags --libs
> -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
> -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/X11R6/include
> -I/usr/include/freetype2 -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include -Wl,--export-dynamic -lgtk-x11-2.0
> -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0
> -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0

The pkg-config path variable that you are using is something nonstandard
that you have created in your development of gEDA, is it not? Redhat 9
doesn't use pkg-config at all in any of its setups. (although I have
installed the latest version as per your instructions...)

>
> Also on my all of my Debian systems (both testing and unstable)
> the above pkg-config gtk+-2.0 also works fine.
>
> I don't think I have personally seen a Linux (or other OS)
> distribution (and I routinely test gEDA/gaf on common distributions and
> configurations) that has renamed gtk+'s pkg name to GTK2.

When I do an rpm -qi on gtk2 I get:

      $ rpm -qi gtk2
      Name : gtk2 Relocations: (not relocateable)
      Version : 2.2.4 Vendor: The KDE-RedHat Project
      Release : 10.6.rh90.kde Build Date: Thu 14 Oct 2004 03:51:04 PM EDT
      Install Date: Sun 31 Oct 2004 08:47:19 AM EST Build Host: math.unl.edu
      Group : System Environment/Libraries Source RPM: gtk2-2.2.4-10.6.rh90.kde.src.rpm
      Size : 8734983 License: LGPL
      Signature : DSA/SHA1, Thu 14 Oct 2004 03:57:07 PM EDT, Key ID efe4780cff6382fa
      Packager : kde-redhat Developers <http://kde-redhat.sf.net/>
      URL : http://www.gtk.org
      Summary : The GIMP ToolKit (GTK+), a library for creating GUIs for X.
      Description :
      The gtk+ package contains the GIMP ToolKit (GTK+), a library for
      creating graphical user interfaces for the X Window System. GTK+ was
      originally written for the GIMP (GNU Image Manipulation Program) image
      processing program, but is now used by several other programs as well.

This is the package you are calling gtk+-2.0.

*and*...

      $ rpm -qi gtk+
      Name : gtk+ Relocations: (not relocateable)
      Version : 1.2.10 Vendor: The KDE-RedHat Project
      Release : 33.5.rh90.kde Build Date: Tue 05 Oct 2004 11:42:52 AM EDT
      Install Date: Sun 31 Oct 2004 08:47:37 AM EST Build Host: math.unl.edu
      Group : System Environment/Libraries Source RPM: gtk+-1.2.10-33.5.rh90.kde.src.rpm
      Size : 2263077 License: LGPL
      Signature : DSA/SHA1, Tue 12 Oct 2004 09:39:43 AM EDT, Key ID efe4780cff6382fa
      Packager : kde-redhat Developers <http://kde-redhat.sf.net/>
      URL : http://www.gtk.org
      Summary : The GIMP ToolKit (GTK+), a library for creating GUIs for X.
      Description :
      The gtk+ package contains the GIMP ToolKit (GTK+), a library for
      creating graphical user interfaces for the X Window System. GTK+ was
      originally written for the GIMP (GNU Image Manipulation Program) image
      processing program, but is now used by several other programs as
      well.

*and*...

      $ rpm -qi gtk+-2.0
      package gtk+-2.0 is not installed

This is the way it has always been on RedHat 9.0 (Shrike)

If I do a search on my library directory, I find:

      $ ls -l /usr/lib/gtk*
      /usr/lib/gtk:
      total 4
      drwxr-xr-x 3 root root 4096 Dec 16 23:35 themes

      /usr/lib/gtk-2.0:
      total 12
      drwxr-xr-x 5 root root 4096 Dec 16 23:35 2.2.0
      drwxr-xr-x 2 root root 4096 Oct 31 08:46 include
      drwxr-xr-x 2 root root 4096 Aug 1 2003 modules

Just like you have.

The problem here is pkg-config doesn't have all of the ".pc" files
stuffed somewhere that describe the packages as gEDA needs to see
them. Who is supposed to supply all this nonstandard stuff?

>
>>$ ldd `which gschem`
>>
>> libstroke.so.0 => not found
>
> [snip]
>
>> libgdgeda.so.6 => not found
>
> [snip]
>
> Yeah, these libraries are in /usr/local/lib, but you need to
> tell ld.so (dynamic linker/loader) where to look for them. You need to
> either 1) set LD_LIBRARY_PATH to point there or 2) add /usr/local/lib
> to ld.so.conf. The final alternative is to use rpath (not recommended
> by various people, but that's a whole different debate), but you would
> have to add that to the Makefiles yourself.

Agreed, I made the change to ld.so.conf, and this problem went away.

>
> [snip]
>
>>In the past, using source and ./configure, make, and make install, it
>
> did
>
>>do the right thing, but this latest 2004 release behaves differently.
>
>
> I haven't really changed how gEDA/gaf is configured or compiled
> in a quite some time, so if you had success with previous releases,
> something else has changed.

I don't understand it either, but I had the previous version of gSchem
working. PCB has worked just fine all along (and still does)

[snip]
> Yeah, sounds like you are running a RedHat 9 system which has
> been upgraded and somehow the upgraded pieces are not what the gEDA/gaf
> ./configure scripts expect.

My configuration is the same as vanilla shrike. My packages have been
upgraded to the latest bug fixes, that is all.
>

>>curious as to why it was taking so long, and why every hour or so I
>
> would
>
>>look at it and it was building the symbols yet again.)
>
>
>
> Yes, I observed this as well and it is a bug. However, if you
> let it run, it will eventually finish (it did for me). I have a pretty
> good idea why this is happening. Stuart and I will fix this for the
> next rev of the suite CD.

Yes, I eventually got busy, and let it run to completion on its own.
The repeated rebuilding of the symbol libraries easily slowed the process down by
10 to 20 times.
>
>
> [snip]
>
>>I have a definite desire for gEDA to succeed, as I think
>>GPL'd software is the future. But at this stage, gEDA 20041228
>>shouldn't have been released to the public. If a guy like me who
>
> [snip]
>
>
> Interestingly enough, 20041228 has been out for ~18 days and
> I haven't heard of anybody else having build problems (using gtk+
> 2.2.x/2.4.x; trying to compile with gtk+ 2.6.x is another matter
> because of a function name clash in my code, already fixed in CVS :-).

18 days isn't all that long. Have you heard of any *new* users that
have successfully built the system? That would be a more interesting
bit of information.

-Chuck Harris

Relevant Pages

  • Re: Exportability of EDA industry from North America?
    ... > if a stock RedHat 9 system really does have so much trouble installing ... RedHat never uses /usr/local/lib for its libraries, ... > standard or similar to the upstream source packages. ... that you have created in your development of gEDA, ...
    (sci.electronics.design)
  • Re: Synaptic / Apt: Check for unused packages?
    ... is there a way to use apt / Synaptic to check for packages / ... distinguish between applications and libraries? ... installing, then the install process sometimes required user-input so ... AFTER the downloading last night.. ...
    (Ubuntu)
  • Re: Why do I get /usr/lib64 on a 32bit machine?
    ... after installing gcc, ... I apt-get removed and dpkg -P'd these packages and the libraries are ... How do I find out what installed these libraries - i.e. discover what ... To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx ...
    (Debian-User)
  • Re: compiling
    ... > applications of interest do not have RPM packages. ... while compiling the latest kernel with gcc 3.3). ... run old games in dosbox without the installation installing old libraries in ... libraries, ldconfig, and configure as well as some C mostly ...
    (alt.linux)
  • Re: Where is Phobos P430 QFE X1034A Driver
    ... The following packages are available: ... Installing Phobos P430 Adapter Driver for 32 bit PCI QuadPort ... devfsadm: driver failed to attach: pqfe ...
    (comp.sys.sun.admin)