FPGA Central

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.

EDA wannabe wrote:
> Can EDA tool development
> be expected to follow suit, is has it already happened?

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

Paul Burke

In article <[email protected]>,
EDA wannabe <[email protected]> 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?

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

> If not, what
>are the factors that differentiate it from design work to make it less
>exportable?

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 <[email protected]>
wrote (in <[email protected]>) about 'Exportability of EDA
industry from North America?', on Thu, 16 Dec 2004:

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

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

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.


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, http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis

In article <aqUz8KBGOYwBFw$[email protected]>,
John Woodgate <[email protected]> wrote:
>I read in sci.electronics.design that Phil Tomson <[email protected]>
>wrote (in <[email protected]>) about 'Exportability of EDA
>industry from North America?', on Thu, 16 Dec 2004:
>
>>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.
>
>Or the standard of living elsewhere will have to rise.

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

Phil Tomson wrote:
>
> 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.


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.

In article <[email protected]>,
EDA wannabe <[email protected]> wrote:
>
>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.

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

Phil Tomson wrote:

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

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

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

In sci.electronics.cad Richard Griffith <[email protected]> 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:
http://sourceforge.net/projects/ngspice

tclspice:
http://tclspice.sourceforge.net/

GnuCap
http://www.geda.seul.org/tools/gnucap/index.html


: digital->?
Icarus Verilog:
http://www.icarus.com/eda/verilog/

Alliance:
http://www-asim.lip6.fr/recherche/alliance/

Confluence:
http://www.launchbird.com/products.html


: 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):
http://www.geda.seul.org/

Electric:
http://www.staticfreesoft.com/index.html

XCircuit:
http://xcircuit.ece.jhu.edu/index.html


: 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:
http://bach.ece.jhu.edu/~tim/programs/magic/index.html

Alliance:
http://www-asim.lip6.fr/recherche/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

Stuart Brorson wrote:

> ngspice:
> http://sourceforge.net/projects/ngspice
>
> tclspice:
> http://tclspice.sourceforge.net/
>
> GnuCap
> http://www.geda.seul.org/tools/gnucap/index.html
>
>
> : digital->?
> Icarus Verilog:
> http://www.icarus.com/eda/verilog/
>
> Alliance:
> http://www-asim.lip6.fr/recherche/alliance/
>
> Confluence:
> http://www.launchbird.com/products.html
>
>
> : 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):
> http://www.geda.seul.org/

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 <[email protected]> wrote:
:> gEDA (has schematic caputre, attribute management, netlisting,
:> archiving, and other utilties useful for design):
:> http://www.geda.seul.org/

: 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 Stuart,

Stuart Brorson wrote:
> In sci.electronics.cad Chuck Harris <[email protected]> wrote:

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

RedHat 9, Workstation, upgraded to the latest fixes on FreshRPM's apt-get
repository.
>
> : 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)

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)

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

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

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

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

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.

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

I very much understand this. But at this time, it is well below the usual
level of documentation found in Gpl'd software.
>
> : 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?

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

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

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]
>> * Linux distro & revision level
>> * Installation flavor (i.e. RedHat comes in "personal",
"workstation",
>> "server", and so on. SuSE comes in "personal" and
"professional").
>
> RedHat 9, Workstation, upgraded to the latest fixes on FreshRPM's
apt-get
> repository.


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:

http://geda.seul.org/download.html

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]
>> : other distributions use differing names for some of the normal
system
>> : libraries. (GTK+ 2 comes to mind)
>
> 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


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.


> 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
[snip]
> $ ls /usr/local/lib/libgdg*
> /usr/local/lib/libgdgeda.a /usr/local/lib/libgdgeda.so.6
[snip]
>
> $ 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.


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


[snip]
>> systems which will and won't work. Did you read the README?
>
> 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.
>

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.


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


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

Thanks for the feedback.

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

In sci.electronics.cad Ales Hvezda <[email protected]> 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:

: http://geda.seul.org/download.html

: 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

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

Stuart Brorson wrote:
> In sci.electronics.cad Ales Hvezda <[email protected]> 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??. . . . .

You will never hear that complaint from me!


> [. . . snip! . . . ]
>
> : I followed the INSTALLs and READMEs that
> : can be found at:
>
> : http://geda.seul.org/download.html
>
> : 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?

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

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)

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

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.

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

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

On Sun, 16 Jan 2005 10:25:16 +0000, Stuart Brorson wrote:

> In sci.electronics.cad Ales Hvezda <[email protected]> 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?

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

On Sun, 16 Jan 2005 10:25:16 +0000, Stuart Brorson wrote:

> In sci.electronics.cad Ales Hvezda <[email protected]> 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.
>
....
> : http://geda.seul.org/download.html
>
> : 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.

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_<etc>,
I was reminded of this:
http://www.visi.com/~barr/ldpath.html

The way I understand it, LD_<etc> 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 <[email protected]> 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

Stuart Brorson wrote:

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

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

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)

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

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

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

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.

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

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

On Mon, 17 Jan 2005 00:26:50 -0500, Chuck Harris wrote:

> Stuart Brorson wrote:
....
>> * 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.
>
> 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)

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

Rich Grise wrote:

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

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

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

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