Exportability of EDA industry from North America?

Some colleagues and I were discussing the situation with the high tech industry, with jobs moving out of North America. This has hit circuit designers hard, especially those in digital. Can EDA tool development be expected to follow suit, is has it already happened? If not, what are the factors that differentiate it from design work to make it less exportable? Comments are also welcome for automatation of methodologies for programmable system-on-chip e.g. reconfigurable processor arrays.

EdWin, the nightmarish Swedish PCB CAD system, has been "developed" in India for several years now.

Paul Burke

It's already happening to a large degree. Most of the big EDA companies have India/China SW R&D offices.

It's just as easy to export EDA development jobs as it is to export circuit design. Might be easier since software developers are readily available.

Probably the best bet if you want an EDA job in the US is to get a PhD, but even some of the highlevel research is starting to move over.

It's not a pretty picture. The standard of living will likely have to fall a good bit in the US before you see these kinds of jobs move back.

Phil

I read in sci.electronics.design that Phil Tomson wrote (in ) about 'Exportability of EDA industry from North America?', on Thu, 16 Dec 2004:

Or the standard of living elsewhere will have to rise.

The removal of WTO quotas for clothing exports from developing countries is said to spell trouble for ... - no, Bangladesh! Apparently India and China can undercut the Bangla manufacturers.

--
Regards, John Woodgate, OOO - Own Opinions Only. 
The good news is that nothing is compulsory.
The bad news is that everything is prohibited.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk

True. We'll have to meet in the middle somewhere. This is partly why the dollar is falling (also because of the national debt, of course). The fact remains that the US standard of living will have to fall in this kind of a free-trade system. It's not going to be pretty for the US standard of living to fall that way - it hasn't really happened before.

Phil

What "high-paying" job? They've all been offshored.

--
Thaas

I understand that there must be some level of parity before the jobs start flowing back. Regarding the comment about a Ph.D., I am actually speaking about the outlook for someone completing an advance degree. Typically, though, the relevance of even R&D tends to follow the prevalence of the associated application, so if the industry practice moves elsewhere, the relevance and value of the R&D is likely to follow (I surmise). So I'm wondering how much the R&D in this area will likely be eroded in North America.

As well, the angle I'm interested in is that of combinatoric algorithms in mapping applications to prefabricated systems-on-chip, or configurable platforms. That might be nonstandard enough to maintain a presence in North America. It all depends on the experience and grounding of alternative, more economic countries in this knowledge area. Especially in terms of university activity.

I would also imagine that the more niche-like the area, the less attractive it is for developing countries. It seems like the road to development typically tries to capitalize on large anticipated markets for a particular skill set or technology. I wonder how much this will protect against erosion of R&D in North America. Of course, any opinions will necessarily be highly speculative, but it would be interesting to hear rationales for them.

Aside from the doom and gloom of predicting the potential decline of an industry and area of R&D, I wonder about the likely challenges in transferring the associated experience into other areas. Combinatoric problems are a very general label, and I'm sure there is much crucial, domain-specific knowledge to make such a skill set valuable.

By the fallback that is observed in automotive, why is it a problem that some manufacturing is swinging back to the U.S. (and some also swung back to Canada, too, by the way)?

Fred

This has been happening for quite some time now. At first (during the "good times") companies have been moving jobs to India and China because there where not enough engineers available in the US. Than during the recession, companies have been moving/continuing to use India and China because they *appear* to be cheaper than local talent.

And I think it is very important to analyze the cost "savings" in greater detail. The truth is that engineers in these developing countries, are less experienced and do not have the needed background of pulling through large projects. As smart as they may be, doing a large project and coordinating some 100 engineers is a tough task. My personal experience with products coming from the developing/low cost countries, is that the quality of workmanship is just not there YET. Many of the "savings" are getting killed because things have to be rewritten/redesigned/fixed/ start over from scratch. Typically the decisions of outsourcing is done by upper management without any feedback from any senior engineers in the US. Managers and engineers are hired in the developing countries with the expectation that they will deliver good of same quality as their US counterparts. So far in my opinion this has not happened (YET !).

I believe that in the next 5-10 years we will see the experience level increase and the quality of products to start reaching the same levels as what we would expect form US based engineers. At the same time, I believe, these engineers expectations will be raising as well. As these engineers become more senior and experienced, many of them will have the opportunity to go to the US and get a "high-paying" job. As such the "cost advantage" together with the lower expectation in the US (which will be in my opinion a natural development) will become a wash.

Overall I believe we will see a few swings back and forth of this outsourcing "problem" the US is facing. After a while this will become irrelevant as all of the developing countries will become also leaders on the same level as the US. I think if the US does not start attracting new internal engineers by providing more incentives for students, it, as a whole country, will eventually fall behind in the technology sector, which will be led by Japan, China and India (in this order - I believe). I believe this fall back, can already be observed in the automotive industry ... And that, will be by far a much larger problem everybody in the US will face than the outsourcing you see today.

Best Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services,

Your Partner for IP Cores, Design, Verification and Synthesis

Then stick with EDA. There is a very good chance that your future job will not be directly related to your course of study in any case. The important thing is to enjoy what you are doing.

-- Mike Treseler

I am beginning to think along these lines as well. Areas like datamining or bioinformatics will likely dwarf EDA in terms of revenue (and thus more jobs will be available in those areas). It might be better to think of Google instead of [Synopsys|Mentor|Cadence|etc] as a potential employer. I also am a grad student (with a lot of years of 'real-world' experience) and whereas I was aiming toward EDA in my studies, now I'm starting to think about branching out into a different area that might be growing faster... but I'm still very interested in EDA.

Phil

I would say it is time for the EDA industry to flip to open source code. All the fabless startups are just killed by the tool expenditures they need to make.

1. OpenSource simulator: analog -> spice digital->? mixed->?
2. Schematic capture
3. Netlister/code capture. I don't think even the professional EDA tools have this right. Why does multiplier.sch or multipler.c have only 1 view. Why not version control/views built into the editor where the netlister can be set to grab different versions or the editor highlight the delta's. A configuration view that sees all views from system level to extracted with all their associated versions and tags.
4. Layout editor/GDS viewer. How many polygons does a video game push?
5. Schematic/Layout/System viewers that allow properties to attach. Wires colored by current, sized by voltage. Visualization tools.

I think the industry needs open source tools.

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

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

In sci.electronics.cad Richard Griffith wrote: : EDA wannabe wrote: :> Some colleagues and I were discussing the situation with the high tech :> industry, with jobs moving out of North America. This has hit circuit :> designers hard, especially those in digital. Can EDA tool development :> be expected to follow suit, is has it already happened? If not, what :> are the factors that differentiate it from design work to make it less :> exportable? Comments are also welcome for automatation of methodologies :> for programmable system-on-chip e.g. reconfigurable processor arrays.

: I would say it is time for the EDA industry to flip to open source code. : All the fabless startups are just killed by the tool expenditures they : need to make.

: 1. OpenSource simulator: : analog -> spice

ngspice:

tclspice:

GnuCap

: digital->? Icarus Verilog:

Alliance:

Confluence:

: mixed->? Not there yet. :-( However, SystemC can be used for this kind of work. Is it synthesizable yet? Are the synthesis implementations open-source? (I don't watch this area that much.)

: 2. Schematic capture

gEDA (has schematic caputre, attribute management, netlisting, archiving, and other utilties useful for design):

Electric:

XCircuit:

: 3. Netlister/code capture. I don't think even the professional EDA tools : have this right. Why does multiplier.sch or multipler.c have only 1 : view. Why not version control/views built into the editor where the : netlister can be set to grab different versions or the editor highlight : the delta's. A configuration view that sees all views from system level : to extracted with all their associated versions and tags.

Not there yet, as far as I know. :-(

: 4. Layout editor/GDS viewer. How many polygons does a video game push?

Magic:

Alliance:

: 5. Schematic/Layout/System viewers that allow properties to attach. : Wires colored by current, sized by voltage. Visualization tools.

Interesting ideas. Who implements these in the commercial world?

: I think the industry needs open source tools.

Here's the problem with open-source EDA: How will developers be able to support themselves while writing the stuff? What's the economic model? Right now it's a hobbiest/academic effort, and the tools are at the point where they are useful to students, hobbiests, consultants, and small businesses. But to really go for the high-end (as you wish), open-source EDA needs to become economically self-supporting.

Linux became economically self-supporting (for some) when big companies like IBM got into it. The companies supporting Linux right now are those who see their business models as selling consulting services, or higher-layer software (e.g. databases, accounting systems) which runs on Linux. To them, Linux is just some plumbing which supports their stuff. The folks who are threatened by Linux (and open-source in general) are those who actually want to sell software as their main line of business.

By analogy, the major EDA houses will not be the folks pushing open-source EDA into the big-time. Rather, it will be design service bureaus and large design houses. However, this is a fragmented industry. There is not a single big player -- like IBM -- with the power and vision to step up to the plate and push open-source EDA within the industry. Also, the design services industry is not flush with cash right now now (due to the general collapse of engineering in the first world), so I doubt they will be hiring teams of software developers to work on open-source EDA apps anytime soon.

Stuart

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

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