Re: Exportability of EDA industry from North America?

The gEDA system is a very nice idea... It is truly a shame that it is packaged with insufficient thought to portability. It wants the system libraries it uses to be stuffed in non standard places inorder for it to find them. It doesn't recognize that Redhat, and some of the other distributions use differing names for some of the normal system libraries. (GTK+ 2 comes to mind)

If you want to install the gEDA system so it is available to all users on a multiuser system, you have to give all of those users root privileges on certain system directories...There is no excuse for that!

All of the example designs are broken in such a way that they cannot find the active components to put on the schematic.

There are no examples or documents describing how the project manager is supposed to work. Saying it is obvious isn't much help.

The CDROM that was issued the other day is even worse than useless. It chugs and churns, but it doesn't notice that it cannot find certain libraries, and it just goes on like everything is ok. It also rebuilds and installs the symbol libraries so many times I thought it was stuck in a loop.

Close, but not quite ready for prime time.

-Chuck Harris

In sci.electronics.cad Chuck Harris wrote: :> gEDA (has schematic caputre, attribute management, netlisting, :> archiving, and other utilties useful for design): :>

: The gEDA system is a very nice idea... It is truly a shame that it : is packaged with insufficient thought to portability.

I'm sorry to hear that you have problems installing gEDA. It seems to work for many other people. I am one of the active developers. Accordingly, I am always interested in specific bug reports so I can then fix problems, and robustify the application. Therefore, can you please be more specific? I'd be happy to fix whatever I can if I had some hard information.

Particularly relevant info:

• Linux distro & revision level

• Installation flavor (i.e. RedHat comes in "personal", "workstation", "server", and so on. SuSE comes in "personal" and "professional").

: It wants the : system libraries it uses to be stuffed in non standard places inorder for : it to find them. It doesn't recognize that Redhat, and some of the : other distributions use differing names for some of the normal system : libraries. (GTK+ 2 comes to mind)

If you build it from source (or use the CD) the "configure" step takes care of all of this -- in principle. If it isn't working for you, we would like to fix it. Please report: Which system libs go in non-standard places, what are the non-standard places, and what method of installation are you using? Also, what type of system do you use (i.e. Linux distro)?

: If you want to install the gEDA system so it is available to all users on : a multiuser system, you have to give all of those users root privileges on : certain system directories...There is no excuse for that!

Which system directories? And what method of installation?

: All of the example designs are broken in such a way that they cannot find : the active components to put on the schematic.

This is an interesting point. I can look into this. I don't know how the lib search paths are set in the examples. I believe they are configurable when you install from source, but if you are using a binary distro, then they might be hardcoded.

: There are no examples or documents describing how the project manager is : supposed to work. Saying it is obvious isn't much help.

True, certain things lack documentation. That problem is being worked, but ever-so-slowly. Please remember that gEDA is a volunteer effort, and getting engineers to document their stuff is not always easy. You probably know this.

: The CDROM that was issued the other day is even worse than useless. It : chugs and churns, but it doesn't notice that it cannot find certain libraries, : and it just goes on like everything is ok. It also rebuilds and installs : the symbol libraries so many times I thought it was stuck in a loop.

Again, what Linux distro & rev level are you using? The CD was tested on several modern Linux variants. In the CD's README are listed the systems which will and won't work. Did you read the README?

: Close, but not quite ready for prime time.

With some work, and specific info about problems, it will become ever more polished over time. Keep in mind that generalized kvetching is cheap 'n easy, but offering bug details will help everybody.

Thank you for your detailed bug report.

Stuart

RedHat 9, Workstation, upgraded to the latest fixes on FreshRPM's apt-get repository.

Redhat 9 calls GTK+ 2.0 GTK2, but your configuration scripts are looking for GTK+-2.0 So they don't find GTK2, and back down to GTK+ 1.2

Your scripts on the latest version of gSchem cannot find the dynamic links for libstroke, or libgdg* , even though they are in /usr/local/lib (with all the other libraries it did find):

$ ls /usr/local/lib/libst*

/usr/local/lib/libstroke.a /usr/local/lib/libstroke.so.0 /usr/local/lib/libstroke.la /usr/local/lib/libstroke.so.0.0.5 /usr/local/lib/libstroke.so

$ ls /usr/local/lib/libgdg* /usr/local/lib/libgdgeda.a /usr/local/lib/libgdgeda.so.6 /usr/local/lib/libgdgeda.la /usr/local/lib/libgdgeda.so.6.0.0 /usr/local/lib/libgdgeda.so

$ ldd `which gschem`

libstroke.so.0 => not found libgeda.so.22 => /home/chuck/gEDA/geda-install/lib/libgeda.so.22 (0x40033000) libguile.so.12 => /usr/lib/libguile.so.12 (0x4006f000) libguile-ltdl.so.1 => /usr/lib/libguile-ltdl.so.1 (0x400fc000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40103000) libgdgeda.so.6 => not found libpng12.so.0 => /usr/lib/libpng12.so.0 (0x40131000) libm.so.6 => /lib/tls/libm.so.6 (0x40154000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40176000) libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x4019b000) libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x402e3000) libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x4031b000) libdl.so.2 => /lib/libdl.so.2 (0x4031f000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40323000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4032b000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40339000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40418000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40421000) libc.so.6 => /lib/tls/libc.so.6 (0x42000000) libgdgeda.so.6 => /usr/local/lib/libgdgeda.so.6 (0x40439000) libz.so.1 => /usr/lib/libz.so.1 (0x4046b000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x40479000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

In the past, using source and ./configure, make, and make install, it did do the right thing, but this latest 2004 release behaves differently.

This comes directly from one of the documentation file included with gEDA. If you install using root, ./configure will put everything in the '/usr/local/' tree, including all of the project files, and other files the user generates. I cannot find the exact doc file where I found this written, but that file says that the users must have write privileges on the /usr/local tree inorder to use the system if it is installed that way. The author made it sound like something that everyone would do... A very stupid windowsesque sort of thing.

All of the transistors, diodes and IC's used in the example programs are located in a subdirector or the individual example program. There is no info present that explains how to encourage gSchem to connect the two. Presumably that info would in the project file used for the project where these examples reside... only no project files are included.

I very much understand this. But at this time, it is well below the usual level of documentation found in Gpl'd software.

libraries,

Absolutely! And I am running RedHat 9, a system that should work... All the versions of my various tools are at or above the rev levels required.

The first time I ran the CDROM install, it built and installed the symbols libraries at least 20 times before I killed the process. (I was getting 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.)

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 has been working with unix for 30 years, and linux since the first slackware distribution can't make your package work, how much chance does anyone else have?

-Chuck

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.

[snip]

"workstation",

"professional").

apt-get

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)

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:

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'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.

[snip]

system

looking for

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

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.

links

(with

[snip] [snip] [snip] [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.

[snip]

did

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.

[snip]

All

required.

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.

symbols

getting

would

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.

[snip] [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 :-).

Thanks for the feedback.

-Ales

--
Ales Hvezda
ahvezda 0x40 seul.org
http://geda.seul.org/

In sci.electronics.cad 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.

Now that's something extraordinary! The main creator of gEDA responds to a bug report on Usenet! When was the last time you saw a developer for Orcad respond to any bug report?

So what was that complaint about F/OSS lacking support??. . . . .

[. . . snip! . . . ]

: I followed the INSTALLs and READMEs that : can be found at:

:

: The only change I made was to add /usr/local/lib into ld.so.conf : (and re-ran ldconfig).

This is an intersting observation; this library is a standard library to store .so files. Why doesn't RedHat already have this in ld.so.conf? Also, I have never had to do this. Is this a libstroke-only thing? I should look into this; I can easily add /usr/local/lib to the LD_LIBRARY_PATH at the start of the install program.

[. . . 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:

Yeah, I've never seen them called anything other than this. If your distro calls them something else, it's a problem with your distro.

Not that that excuses a failed install. Rather, the capability to configure for this name for GTK should be built into the installer. Again, what is your distro, and where did you get it? Can you point to web documentation about this change to GTK? I'd like to check into this oddity.

:> The first time I ran the CDROM install, it built and installed the : symbols :> libraries at least 20 times before I killed the process. (I was : getting :> 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.

This occurred because the installer configured each program individually, and each program had the symbols in its dependency tree. Therefore, the symbols were blindly rebuilt for each program in the suite. If you had let the program churn along (as it says in the README), you would have eventually gotten through this.

Anyway, we will change the way dependencies are handled in the next build. We take real, substantive, detailed bug reports seriously; fixing issues which users notice is how F/OSS is hardened over time.

Stuart

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.

That is precisely the version I am running.

As did I.

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)

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

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...)

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 URL : 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 URL : 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?

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

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]

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

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. 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

You will never hear that complaint from me!

RedHat puts all of its user libraries in /usr/lib. Debian uses both /usr/lib, and /usr/local/lib. gEDA installs its dynamic libraries in /usr/local/lib, but doesn't bother to check the ld.so paths.

....Also, I have never had to do this. Is this a

Nope! GTK2 is what redhat has always called this package.

Do an "rpm -qi gtk2" on your system. I bet it comes up the same as mine does. All of the appropriate libraries for gtk+ 2.0 are in their standard places in my directory tree (/usr/lib/gtk-2.0)

I am certain the problem comes from RedHat not using pkg-config at all in their system. As a result, there isn't a directory full of '.pc' files that describe all of the packages installed in the system.

After several hours, and my observing the symbols getting rebuilt repeatedly, I shut it down. I ran it again, and got busy and walked away (scary to do with a root installer!) and it had completed.

-Chuck Harris

Once I figured out that gEDA might be something to look at, I went to the site, and reading the FAQ, I had a very .. kewl .. feeling come over me when he says, "Config files will always be ASCII text, because I said so."

Right On! ;-)

I plan on installing it with Slack tools, and possibly come up with a "real" Slack package, although I should try RPM2tgz first.

And, by the way, Thanks!

Cheers! Rich

...

Two things: I have Slack 10.0, and /usr/local/lib is the first entry in my ld.so.conf already, and when I read Ales's recommendation to use LD_, I was reminded of this:

The way I understand it, LD_ was intended as a temporary thing, for development or something; essentially, they say don't use it because it's a clooge. (not that I would have the G*D* gall to complain to one who has put his heart and soul into a work of GPL-ware. :-) )

Thanks! Rich

In article you wrote: : 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.

OK, this is getting interesting. Here are the issues noticed, and their resolution:

• gschem wants /etc/ld.so.conf to have a link to /usr/local/lib in it. I am suprised that it is not in RH9, but I'll take your word for it. Yes, I know that RH puts all it's stuff in /usr/lib & most GNU goes by default into /usr/local/lib. They each adhere to a different standard -- there are so many to choose from!

We will look at checking & setting LD_LIBRARY_PATH to include /usr/local/lib when the setup program runs.

• pkg-config. Pkg-config is a configuration utility which reports back info about what compile and load flags should be set when building a package. It is not new, nor specific to any distribution. It's used by configure and make when doing a build. I think it was introduced by the gtk folks themselves. Here's an example run, for a totally random package, openssl:

[sdb@localhost /etc]$ pkg-config openssl --cflags

-I/usr/kerberos/include

It returns the compiler flag -I/usr/kerberos/include, which tells gcc where to find my kerberos/include stuff.

Pkg-config should live on your system too. It calls the gtk2 stuff "gtk+-2.0", and returns the following:

[sdb@localhost /etc]$ pkg-config gtk+-2.0 --cflags

-I/usr//include/gtk-2.0 -I/usr//lib/gtk-2.0/include

-I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0

-I/usr/include/freetype2 -I/usr//include/glib-2.0

-I/usr//lib/glib-2.0/include

Try that out on your system too. You should get a similar result.

Anyway, I think you and Ales are having a nomenclature disagreement. The RPM calls it gtk2, but pkg-config (which is used in configuring and making gEDA) calls it gtk+-2.0.

• Symbols. The installer *did* run to it's end once you left it alone. We agree that there was a dependency issue causing each gEDA/gaf program to remake the symbols as it built each program in sequence. Next time, just relax and let it build.

How long did you let it spin before you pulled the plug, anyway? A typical install session with the CD can run 1 -- 2 hours, depending upon the speed of the machine.

• Installing into /usr/local/bin. Actually, for the installer, I recommend installing your sources into /usr/local/src/geda-sources, (maybe geda-sources-20041228, or whatever version you use) and installing your executables into /usr/local/geda. Then put /usr/local/geda into your $PATH. That way you can nuke it if you ever need to.

:> 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.

We have tested this new installer on several machines with several people, but they all knew what they were doing (gEDA-wise, that is). A total newbie install is the experiment we are running on you.

Stuart

The use of LD_LIBRARY_PATH has been depreciated for years. I was rather perturbed when gEDA dredged it up and made me set it. It is a seriously bad idea to use it in a global way on any system.

Pkg-config does live on my system, but it does nothing interesting because there are no .pc files on my RH9 system. AFAIK there never were. I have compiled numerous packages, and gEDA is the first I have found that requires pkg-config. Further, your detection of gtk2 is the only package in gEDA that ./configure misses. Until I built my first version of gEDA, PKG_CONFIG_PATH wasn't even set on my machine. (I cannot prove it, but I don't think it is set by any RH9 system)

Again, your incantation of ./configure cannot find gtk2 on my system, but it has no trouble finding gtk+. When it decides it cannot find "gtk+-2.0" it checks for gtk+ (version 1.2something), finds it and goes along merrily.

I'm running a 666 MHz machine, and I waited several hours before I decided (mistakenly) that it was spinning its wheels. I tried it later, and let it spin until completion. I would guess that this installer bug increases the compile and install time by about 10 times.

I am 99% sure that there is some info in the installer's documentation that says if you install as root, it will automatically put everything in /usr/local/, and that includes the project files. I *know* I read that somewhere in gEDA's documentation, and it seems to behave that way with the ./configure type of install. I distinctly remember reading something that said you needed to give all users r/w access to the /usr/local/ directory tree. This is something that I do not want to have, so I have been doing my installs in user mode.

Don't be insulting, I had the previous version of gEDA working on my system before I tried to use the 20041228 install CDROM.

I have been using gerbv for years now. I had zero problems compiling and installing it.

-Chuck

Here's part of why I don't like Redmond^H^H^H^HHat: richgrise@thunderbird:/opt/gEDA/Source/glib-2.4.8 $ cat /etc/slackware-version Slackware 10.0.0 richgrise@thunderbird:/opt/gEDA/Source/glib-2.4.8 $ uname -a Linux thunderbird 2.4.26 #6 Mon Jun 14 19:07:27 PDT 2004 i686 unknown unknown GNU/Linux richgrise@thunderbird:/opt/gEDA/Source/glib-2.4.8 $ find / -name "*.pc" -print 2> /dev/null | wc 120 120 4470 richgrise@thunderbird:/opt/gEDA/Source/glib-2.4.8 $ ls -l /var/log/packages/gtk*

-rw-r--r-- 1 root root 10282 2004-06-26 09:13 /var/log/packages/gtk+-1.2.10-i386-3

-rw-r--r-- 1 root root 45775 2004-06-26 09:13 /var/log/packages/gtk+2-2.4.3-i486-1 richgrise@thunderbird:/opt/gEDA/Source/glib-2.4.8

I'd never heard of .pc files until I stumbled onto this thread, and I've been a Slacker for a number of years.

But I have heard that Redmond^H^H^H^HHat changes configurations from what works out of the box, such that you have to use Redmond^H^H^H^HHat RPM's or it won't install right. There are Slack precompiled packages, or at least they come with an install script that results in a binary and configs that are the same as if you'd run ./configure, make, and install from source. From what I've heard, RH doesn't do it that way. They modify everything.

This is much too close to the Gates of hell for comfort, for me.

Thanks, Rich

GNU/Linux

/var/log/packages/gtk+-1.2.10-i386-3

/var/log/packages/gtk+2-2.4.3-i486-1

I have done some digging on my system, and found that the only use of pkg-config is in gui applications that use the gtk* system. I did some manual page reading and found that pkg-config is a reworked version of a utility that used to be called gtk-config.

Ok, here's the rub: pkg-config is an attempt at making it easier to rebuild packages. It gives you somewhat useful information about the various compile and link options used in building a compliant package. But outside of gtk based gui applications, *nobody* uses it.

And here's what is wrong with pkg-config. It has a built-in structure of paths to the various .pc files that are used to describe the system. The decision on what paths to incorporate in pkg-config is made by the install part of the "./configure, make, make install" sequence used to build pkg-config. It bases the paths on where it was originally aimed at installation. But it would appear that there is no documented way of asking the utility pkg-config what its default search paths are! And it would also appear that there is no system wide configuration file for pkg-config that allows you to tell it what directories to look in for .pc files. Just the kludge PKG_CONFIG_PATH, which, like LD_LIBRARY_PATH, is intended for test builds *ONLY*; things like checking to see if a new version of a library creams your system. Never for distributed packages!

Now, why doesn't *my* pkg-config work. Well, a quick look shows me that my version was built on December 17th, 2004. I was futzing around with an earlier version of the gEDA suite around then. I wanted to see if I could run a trial design from schematic to pc layout. Because of the problem I had with gSCHEM linking up to transistor symbols, I tried rebuilding the system using the some mechanism or other, I forget now.

Well, when I rebuilt the system I must have allowed the fool thing to install its own version of pkg-config over my native version. Only problem is the version was installed based in my home directory, so pkg-config's default search paths are based in /home/chuck/gEDA, which doesn't point to any useful .pc files.

PHBBBBBT!!!

I really hate it when folks use nonstandard stuff in distributions!!!

-Chuck

OBTW, Rich, when I first started linux it was with Yggdrisle's Slackware linux. My problem was *their* distribution couldn't be built from source because they put everything in the wrong places. They broke the many "#include ../../../../../../../foo.h" references that are endemic to unix programs. With RedHat, everything was where it belonged. I could build everything from sources without a hitch.

As time passed, Slackware got smart and fixed their distribution, and RedHat got lazy and fixed everyone elses programs to match their file system layout ....sigh!

I want to go to Debian, but I am finding it hard to get excited about ripping my system apart and starting over...If only there was a safe and easy way to move from RedHat to Debian...

Hi Ales and Stuart,

I have finally spent the time to track down all of the problems I was having installing the gEDA suite, and I now think I have a successful build from using the CDROM.

The two things that messed up my build were:

1) I installed pkg-config using the package included with gEDA, only I think I built it as user, and installed it as root. This made the search paths all be based in my home directory, and not in /usr. My redhat installed pkg-config was in /usr/bin, and my gEDA installed pkg-config was in /usr/local/bin. /usr/local/bin comes first in my path, so I was working with the defective version. That's what I get for trying to upgrade pkg-config outside of the rpm/apt-get system.

2) my /etc/ld.so.conf file was stock RedHat, with some additions by other package installations. It did not include /usr/local/lib in its search paths.

Problems/complaints:

1) I don't like to see LD_LIBRARY_PATH and PKG_CONFIG_PATH globally set. They provide a capability for testing new versions of system libraries. I don't believe they were intended to be used system wide. For that you should add the path to the appropriate /etc/xxxx.conf file. It's a shame there isn't one for pkg-config (AFAIK)

2) The schematics in the examples are all composed of main pages with the transistors and diodes being subpages. There is no obvious (to me the new user) way of making the link so the transistors appear on the schematic. Examples are presumably meant for new inexperienced users, and as such should work flawlessly.

3) There are no examples of projects for use with the gEDA project manager.

4) I know it is easier for the developer to run ./configure at the root of each package, but there ought to be a way to only do it once for the whole system when you are using Stuart's installer program.

5) There is really no good reason to rebuild and reinstall the symbols a dozen or more times. It significantly adds to the build time.

Anyway, it seems to be running, and I will begin to explore the construction of a project from start to finish. I'm sure that task will keep me quite busy.

Thanks for the help, and inspite of the problems I had installing, please know that I think you guys have done a magnificent jog thus far.

-Chuck Harris

The EDA vendors only support RedHat, so I'm sticking with it, whatever its faults. And, finally, after all these years, we now actually have a professional Linux distribution, that's not just put together by hackers. But I'll tell you what really pi**es me off about it - they now charge an *annual* subscription for it. I've been buying Windoze distributions for 20-odd years, and I've never once had to pay an annual subscription. I bought my current Win2K 4 years ago, and I can still download updates and security fixes for free. What exactly makes RedHat think that they can charge year-on-year for that? If they'd just asked me for a one-off $200 then I'd have paid it. I'm running FC2 now, despite having to download the whole thing.

Rick

[. . . snip! . . . ] : Problems/complaints:

: 1) I don't like to see LD_LIBRARY_PATH and PKG_CONFIG_PATH globally set. : They provide a capability for testing new versions of system libraries. : I don't believe they were intended to be used system wide. For that : you should add the path to the appropriate /etc/xxxx.conf file. It's : a shame there isn't one for pkg-config (AFAIK)

: 2) The schematics in the examples are all composed of main pages with : the transistors and diodes being subpages. There is no obvious (to me : the new user) way of making the link so the transistors appear on the : schematic. Examples are presumably meant for new inexperienced users, : and as such should work flawlessly.

: 3) There are no examples of projects for use with the gEDA project manager.

: 4) I know it is easier for the developer to run ./configure at the root of : each package, but there ought to be a way to only do it once for the whole : system when you are using Stuart's installer program.

: 5) There is really no good reason to rebuild and reinstall the symbols a : dozen or more times. It significantly adds to the build time.

: Anyway, it seems to be running, and I will begin to explore the construction : of a project from start to finish. I'm sure that task will keep me quite : busy.

: Thanks for the help, and inspite of the problems I had installing, please : know that I think you guys have done a magnificent jog thus far.

Thanks! We take your bug reports seriously, and will soon do another CD release with at least some fixes to the problems you discovered. I will take a look at the examples today. Keep watching the project page:

Stuart

In sci.electronics.cad Chuck Harris wrote: : Problems/complaints:

: 2) The schematics in the examples are all composed of main pages with : the transistors and diodes being subpages. There is no obvious (to me : the new user) way of making the link so the transistors appear on the : schematic. Examples are presumably meant for new inexperienced users, : and as such should work flawlessly.

Please help me improve the linkage between these schematics. Is your point that you can't open the lower-level schematics from the top level schematic via "Hierarchy -> Down Schematic"? If so, it was a bug in the examples; I have just fixed it.

If you want, try the fix. Edit your gafrc (living in the RF_Amp directory), and add the line (on a new line):

(source-library ".")

Then, open MSA-2643.sch, double click on Q1, and add the following attribute to it:

Attrbute name: source Attribute value: Q1.sch

Do the analogous thing for Q2. Then you should be able to use "Hierarchy -> Down Schematic" in the top menu bar to dive into the models for Q1 & Q2.

Please let us know if this works for you.

Thanks,

Stuart

There is no reason that you have to pay RedHat. The amount you pay is purely for their support. You can get the entire distribution from a number of places. One is

-Chuck

Hi Stuart,

Ok, I have figured out what's going on. If you cd to the directory that the RF_Amp is in, and then invoke gschem, Open page and select the MSA-2643.sch drawing, everything works the way you all probably expected it to.

However, if you are in some miscellaneous directory, and invoke gschem, Open page, and wind your way through the directory structure until you find the MSA-2643.sch drawing, and open it, then you get a schematic with blank spots where the transistors should be.

So, what is happening is you only read the gafrc file for the directory that you are in when gschem is invoked.

What to do? It doesn't seem too unreasonable for a person to be able to start up the geda tools from any old directory they happen to be in and browse their way to the design files using open page, and expect the right thing to happen.

It seems to me that a reasonable solution would be to have gEDA tools read any appropriate rc files found in the directories where you open a new, or old page. I am unsure what would be the best solution for opening a new page in a new empty directory. Perhaps if the directory is created from within the gEDA tools, the directory should be prefilled with an rc file from some template directory?

-Chuck