Re: Exportability of EDA industry from North America?
From: Chuck Harris (cf-NO-SPAM-harris_at_erols.com)
Date: 01/16/05
- Next message: Rich Grise: "Re: Exportability of EDA industry from North America?"
- Previous message: Chuck Harris: "Re: Exportability of EDA industry from North America?"
- In reply to: Stuart Brorson: "Re: Exportability of EDA industry from North America?"
- Next in thread: Rich Grise: "Re: Exportability of EDA industry from North America?"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 16 Jan 2005 18:06:17 -0500
Stuart Brorson wrote:
> In sci.electronics.cad Ales Hvezda <ahvezda@seul.org> 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
- Next message: Rich Grise: "Re: Exportability of EDA industry from North America?"
- Previous message: Chuck Harris: "Re: Exportability of EDA industry from North America?"
- In reply to: Stuart Brorson: "Re: Exportability of EDA industry from North America?"
- Next in thread: Rich Grise: "Re: Exportability of EDA industry from North America?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
