Re: libgfortran.so.1
On Friday 29 August 2008 08.31.07 Francesco Pietra wrote: > Hi Anders: > Being unfamiliar with that type of installation of libraries, in the > fear of damaging the system I have not yet tried. You can always configure and build gcc and then copy libgfortran.so.1.0.0 and its symlinks to i.e. /usr/local/lib[64]. Another option is to install the gcc-suite with --prefix=/opt/gcc-x.y.z, run 'make -n' before installing to ensure nothing gets overwritten by accident. > Easier for me would be a soft link. Do you know if the other libraries > below can do the runtime job of libgfortran.so.1? I don't think that would work. Usually the so-version is bumped on a library when changes in the library interface has made it incompatible with the previous version. Adding symlinks like that will probably generate segfaults sooner or later. > Why the package libgfortran1 for the latter is available for i386 > lenny and not amd64 lenny? Is any backports for the latter? Hmm, I only find libgfortran.so.1 in Etch. Is your libgfortran.so.1 in i386 something left from an dist upgrade? > Thanks > francesco // Anders > On Thu, Aug 28, 2008 at 9:45 PM, Anders Lövgren <[EMAIL PROTECTED]> wrote: > > On Thursday 28 August 2008 20.44.39 Francesco Pietra wrote: > >> Hi: > >> While working with a gnu docking package, I am finding several > >> instances where amd64 lenny discovers errors in binaries compiled with > >> other linuxes, though offered for amd64. The developers confirmed > >> their problems, which were solved. > >> > >> Now, after fixing that the package was unable to find libg2c.so.0, the > >> package asks for > >> > >> libgfortran.so.1 > >> > >> does not find it and halts. Actually, what is available on my > >> installation of amd64 lenny, what is available is: > >> > >> libgfortran.so > >> libgfortran.so.3 > >> libgfortran.so.3.0.0 > >> libgfortran.so.9 > >> libgfortran.so.9.0.0 > >> libgfortran.so.4 > >> and many other, though not .so.1. > >> > >> As far as I could investigate, libgfortran.so.1 is not available for > >> amd64 lenny (it is for i386 lenny, as available on my desktop). > >> > >> A solution? > >> > >> Thanks a lot > >> francesco pietra > > > > Hi Francesco, > > > > The libgfortran.so.1 library gets installed when building gcc 4.1.x from > > source with fortran language enabled in the configure options. > > > > // Anders > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact > > [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libgfortran.so.1
On Thursday 28 August 2008 20.44.39 Francesco Pietra wrote: > Hi: > While working with a gnu docking package, I am finding several > instances where amd64 lenny discovers errors in binaries compiled with > other linuxes, though offered for amd64. The developers confirmed > their problems, which were solved. > > Now, after fixing that the package was unable to find libg2c.so.0, the > package asks for > > libgfortran.so.1 > > does not find it and halts. Actually, what is available on my > installation of amd64 lenny, what is available is: > > libgfortran.so > libgfortran.so.3 > libgfortran.so.3.0.0 > libgfortran.so.9 > libgfortran.so.9.0.0 > libgfortran.so.4 > and many other, though not .so.1. > > As far as I could investigate, libgfortran.so.1 is not available for > amd64 lenny (it is for i386 lenny, as available on my desktop). > > A solution? > > Thanks a lot > francesco pietra Hi Francesco, The libgfortran.so.1 library gets installed when building gcc 4.1.x from source with fortran language enabled in the configure options. // Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: boot screen
On Friday 23 May 2008 23.56.31 Philip Bernstein wrote: > Hi, > >Thanks but I probably should have given out more info here. That > file or path does not exist on my system. I am running on an AMD64 bit > machine with a Nvidia graphics card (GeForce 7300GT) 2 gig memory. In > my /usr/src directory I have the following: > "linux-headers-2.6.24-17-generic" I ran find on it and came up with: > /usr/src/linux-headers-2.6.24-17-generic/include/config/fb/vesa.h which > in this case is a zero byte file. I am running Kubuntu 8.04 with all > the latest updates (this worked this way even in Kubuntu 7.10). Hi, The file vesafb.txt is from the documentation bundled with the kernel source. Heres an excerpt from vesafb.txt that documents the possible VESA video modes: | 640x480 800x600 1024x768 1280x1024 +- 256 | 0x3010x3030x3050x307 32k | 0x3100x3130x3160x319 64k | 0x3110x3140x3170x31A 16M | 0x3120x3150x3180x31B I don't know anything about Kubuntu's kernel configuration, but you can check the output from the vesafb kernel code by running 'dmesg | grep vesafb' in an terminal to verify that the kernel supports vesafb and can access the video memory direct. // Anders > Anders Lövgren wrote: > > On Tuesday 20 May 2008 12.49.03 Philip Bernstein wrote: > >> Hi, > >> > >> I have several systems and on them when I boot I can see all the > >> info scroll across the screen with OK or FAIL (on the right hand side) > >> depending on how things go (in menu.lst I have removed from the boot > >> lines "splash" so I don't get the boot splash). > >> But on my amd64 system the boot messages are quite large and I can't see > >> the OK or FAIL indicators (on the right hand side of the display). Now > >> on the other systems I see that there is on the boot line in menu.lst > >> "vga=791". I tried to put that in the amd64 menu.lst and all I get is a > >> blank screen during boot up. After the system boots, everything is fine > >> and get my graphics back and all works. Anyone notice this during > >> there boot up and found how to reduce the graphics on boot up so you can > >> see whats going on? > >> > >> -- > >> Philip Bernstein > >> [EMAIL PROTECTED] > > > > Hi, > > > > The vga=xxx values usually depends on the monitor, look inside the > > file /usr/src/linux/Documentation/fb/vesafb.txt. For my 19" LCD I use > > vga=0x31b (1280x1024, 32-bit). > > > > You may also need something like video=vesafb:1280x1024-32 to get it > > working. > > > > // Anders > > -- > Philip Bernstein > [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: boot screen
On Tuesday 20 May 2008 12.49.03 Philip Bernstein wrote: > Hi, > > I have several systems and on them when I boot I can see all the > info scroll across the screen with OK or FAIL (on the right hand side) > depending on how things go (in menu.lst I have removed from the boot > lines "splash" so I don't get the boot splash). > But on my amd64 system the boot messages are quite large and I can't see > the OK or FAIL indicators (on the right hand side of the display). Now > on the other systems I see that there is on the boot line in menu.lst > "vga=791". I tried to put that in the amd64 menu.lst and all I get is a > blank screen during boot up. After the system boots, everything is fine > and get my graphics back and all works. Anyone notice this during > there boot up and found how to reduce the graphics on boot up so you can > see whats going on? > > -- > Philip Bernstein > [EMAIL PROTECTED] Hi, The vga=xxx values usually depends on the monitor, look inside the file /usr/src/linux/Documentation/fb/vesafb.txt. For my 19" LCD I use vga=0x31b (1280x1024, 32-bit). You may also need something like video=vesafb:1280x1024-32 to get it working. // Anders -- Thinking is dangerous. It leads to ideas. -- Seen on #Debian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: compiz-fusion
On Tuesday 22 April 2008 12.54.20 can comert wrote: > my uname -ar output is > Linux debian 2.6.24-1-amd64 #1 SMP Thu Mar 27 16:52:38 UTC 2008 x86_64 > GNU/Linux > i'm using testing version > i installed nvidia driver after that i type compiz on synaptic and i > installed all packets except compiz gtk > i type compiz on console and output is like that > [EMAIL PROTECTED]:~$ compiz > Fatal: Failed test: Composite extension > Checks indicate that it's impossible to start compiz on your system. > [EMAIL PROTECTED]:~$ > > how can i solve this problem or is there a guide to re-install > compiz-fusion??? > Thanks for your help... Do you have the composite extension enabled in /etc/X11/xorg.conf? Section "Extensions" Option "Composite" "Enable" Option "RENDER" "Enable" EndSection Is it loaded? bash$ xdpyinfo | grep Composite // Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Error message 'std::bad_alloc'
On Thursday 17 April 2008 16.09.38 Francesco Pietra wrote: > Hi: > OK. However, as my experience with compilations is very limited, could you > give a web indication where to learn how to "build with debug info and run > it under gdb and/or valgrind". Meanwhile I am starting a molecular dynamics > simulation. As soon as completed (1-3 days, have not yet checked the speed > of the new machine) I'll follow your indications. Thanks > francesco pietra Hi Francesco, Run the compiler (g++) with the -g flag to add debug info (configure the source using 'CXXFLAGS="-g" ./configure' should do the trick). You can debug the application by running gdb as 'gdb --args '. When it dies, type bt to dump the callstack. // Anders > --- On Thu, 4/17/08, C. Ahlstrom <[EMAIL PROTECTED]> wrote: > > From: C. Ahlstrom <[EMAIL PROTECTED]> > > Subject: Re: Error message 'std::bad_alloc' > > To: "Francesco Pietra" <[EMAIL PROTECTED]> > > Cc: "Lennart Sorensen" <[EMAIL PROTECTED]>, "debian64" > > Date: Thursday, April 17, 2008, 4:02 AM > > Francesco Pietra 15:29 Wed 16 Apr > > > > >> >The std:: would to me make me think C++ > > > > namespace > > > > >> 'std' function > > >> > > >> >'bad_alloc'. So probably a bad_alloc > > > > function > > > > >> exists in C++ and is > > >> > > >> >returning an error. > > >> > > >> It is a standard exception thrown when the new() > > > > operator > > > > >> fails. > > >> > > >> Your running out of RAM, perhaps. > > >> > > >> Do you build this program yourself from source? > > > > > >Yes (g77-3.4 g++ 4.1.2 lib2c0-dev) from the configure > > > > file provided by > > > > >developers. No errors in either the serial or parallel > > > > compilations > > > > >(openmpi). Also, there is a very long test for both the > > > > serial and > > > > >parallel execution. All passed with a few marginal > > > > warnings for > > > > >different precision on different machines. Finally, > > > > docking of a > > > > >slightly smaller ligands occurs with no errors. > > > > I'd build with debug info and run it under gdb and/or > > valgrind. Might > > tell you where it is messing up. > > > > -- > > I develop for Linux for a living, I used to develop for > > DOS. > > Going from DOS to Linux is like trading a glider for an > > F117. > > (By [EMAIL PROTECTED], Lawrence Foard) > > > > > > -- > > To UNSUBSCRIBE, email to > > [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact > > [EMAIL PROTECTED] > > > ___ >_ Be a better friend, newshound, and > know-it-all with Yahoo! Mobile. Try it now. > http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
