Surfing Troves: 2010

Friday, December 31, 2010

uninterruptedly running program in the background but need enter password or something ?

For instance, wanna copy a big file, more than 10G, say, from remote host to local machine by a shell like :

scp -r user@hostname/ip:/home/data/bigdata /home/user/

but fearful of the interruption if the session will be terminated, so use nohup to achieve an interrupted execution to guard against being drawn to end due to the termination somehow of the current login session. by

nohup scp -r user@hostname/ip:/home/data/bigdata /home/user/

But most of the time you also want to lay this task go in the background since it should take a multitude of time to remote-copy a file as big as 10G, so change into

nohup scp -r user@hostname/ip:/home/data/bigdata /home/user/ &

By this point it comes what I want to share: you are guaranteed to run across an OOPS:

nohup: ignoring input and appending output to `nohup.out'

[1]+ Exit 1                  nohup scp -r user@hostname/ip:/home/data/bigdata /home/user/

this is just because the process is suspended to receive a user input for password.

So there seemingly exists an ambivalent occasion here. By session controlling command, we can circumvent around this plausible dilemma:

nohup scp -r user@hostname/ip:/home/data/bigdata /home/user/
enter the password
CTRL+Z ( force the foreground process back to the background to run like a daemon )
[1] 3581

bg $jobid (you can see the jobid appearing after CTRL+Z, here it is 1)

Later if wanna change it back to run in the foreground, do it by

fg $jobid.

* you can also change the default output of nohup and include all the copying log into a self-defined log file by

nohup scp -r user@hostname/ip:/home/data/bigdata /home/user/   1> bigdata.scp.log 2>&1

Restore Linux installation after installing Windows 7 which overwrote the MBR

By default Linux uses the grub Bootloader to manage OS booting with support of multiple OS, and this makes Linux, Fedora distribution say, really gentle as it is generous to keep its predecessors in the context of multiple boot of operating systems.

As such if you install Linux on top of current Windows system, the installer simply adds an boot item for the existing windows start up. It is not true the other way around, however!

When you install a Windows OS on top of current Linux, windows bootloader will not care about things already exist and bit of bluntly overwrite the grub bootloader thus make you lose the Linux boot.

Good news is there do be a way to remedy this loss, the marvellous guy I will be thankful to get the grub back is grub4dos.

Here we go from Windows 7!

1. Download grub4dos from sourceforge at http://sourceforge.net/projects/grub4dos/files/GRUB4DOS/grub4dos%200.4.4/grub4dos-0.4.4.zip/download

2. unpack and retrieve following files

glrdr

glrdr.mbr

menu.lst

place them under the root directory of the boot partition in Windows like C:\

3. expand a slot for the grub bootloader in current Windows bootloader (bootmgr) using bcdedit :

bcdedit /create /d "Grub4Dos" /application bootsector

note to record the id generated in the output.

then use this same id with following commands:

bcdedit /set {id} device partition=C:
bcdedit /set {id} path \grldr.mbr
bcdedit /displayorder {id} /addlast

As a result this will add an item for grub4dos in the Windows bootloader, so that we can boot Linux through grub4dos indirectly.

4. add boot item in the grub bootloader

edit menu.lst to make sure it contains item(s) for the "lost" Linux boot, it should seem like the example below:

default 0
timeout 3
hiddenmenu title Windows 7
find --set-root --ignore-floppies /bootmgr
chainloader /bootmgr

title Fedora (2.6.31.5-127.fc12.x86_64)
root (hd0,0)/boot
kernel /vmlinuz-2.6.31.5-127.fc12.x86_64 ro root=/dev/sda1 LANG=zh_CN.UTF-8 KEYBOARDTYPE=pc
KEYTABLE=us rhgb quiet
initrd /initramfs-2.6.31.5-127.fc12.x86_64.img

title fedora (2.6.32.21-168.fc12.x86_64)
root (hd0,0)/boot
kernel /vmlinuz-2.6.32.21-168.fc12.x86_64 ro root=/dev/sda1 LANG=zh_CN.UTF-8 KEYBOARDTYPE=pc
KEYTABLE=us rhgb quiet
initrd /initramfs-2.6.32.21-168.fc12.x86_64.img

If you do not remember what the file names are such as initramfs-2.6.31.5-127.fc12.x86_64.img and vmlinuz-2.6.31.5-127.fc12.x86_64, esp. those other values like the stuff on the kernel line (" root=/dev/sda1 LANG=zh_CN.UTF-8 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet), you can
find a tool to look at the /boot/grub/grub.conf in the current Windows, a reliable one I have ever use is ext2fs which can be downloaded from http://www.chrysocome.net/explore2fs. For other similar tools, Google around with "ext file explorer for windows".

5. Now restart windows, in the boot menu, select "Grub4Dos" you will see the classical GRUB interface and you can select the Linux boot item with different kernel version therein. By this, we get Linux installation back and enjoy the dual or multiple boot at one host. In fact the Linux boot restoration steps described above is somewhat similar to that for fresh installation of Linux from Windows 7 without using a Boot CD/DVD.

Further problems are welcome to be posted as comments below.

How to restore or upgrade Fedora linux without losing user data at all

When you are inflicted with some faults of current Linux, the Fedora distribution, say, you might want to restore the OS kernel only without impairing all current user data even user applications installed after the previous installation, just like for Windows 2000/NT/XP/7, etc. there is a "restoring installation" option during the installation tour.

Just follow steps below to achieve this, given all your user data including configurations and profiles even history records like cookies, etc. are located at /home/user, and /home is mounted differently from the OS kernel and its legacy things. For example, you have "df -h" leading to output like following things:

/dev/sda1              99G 7.5G   86G   8% /
tmpfs                 2.0G 468K 2.0G   1% /dev/shm
/dev/sda2             148G   70G   71G 50% /home

[ For upgrading to a higher version of Linux even to a different distribution, the guide below is just exactly suited ]

1. download and place installation package
a. get the OS installation image, Fedora-14-x86_64-DVD.iso, say from the official site

b. extract files and directories from the image and copy them to the partition holding data you want to keep, e.g. the /home at /dev/sda2 in this case

su
mkdir /mnt/fcinstall
mount -o loop -t iso9660 Fedora-14-x86_64-DVD.iso /mnt/fcinstall

cp -fr /mnt/fcinstall/isolinux/{vmlinuz,initrd.img} /mnt/fcinstall/images /home
mv Fedora-14-x86_64-DVD.iso /home

* you can also use some unpacking tool for extracting from ISO instead of using mount.

2. edit /boot/grub/grub.conf and add following :
(presuming current partition is (hd0, 0) in terms of (hard_drive, partition), corresponding to sda1 listed above in this case)

title fcinstall
root (hd0, 0)
kernel /vimlinuz
initrd /initrd.img

*this is to prepare for a boot item in the bootloader for reinstalling. You can either add a new item exclusively for this reinstallation like above
or just modify the bootloader item for the Linux in the current use,

3. keep everything you want to retain AWAY from the OS partition, for example, all stuff other than that are under /home/. if you have ever installed VirtualBox and created an virtual windows Xp image as the root account, you will need to :
move /root/.VirtualBox /home/user, say. this step is the first IMPORTANT really.

4. after ascertaining nothing missed on the /home partition as the user data to keep, restart now

5. following steps is verisimilar to the ordinary fresh installation of Linux, except certain cautions as follows:

a. at this step

CHOOSE "create custom layout"

b. in the partition editing interface,
choose /dev/sda1 to edit, and mount it onto "/", and format it. (it is advisable to format it since we want to a clean fresh installation not patching things up or left garbage there). Should format into "ext4" file system as well.

and, choose /dev/sda2 to edit, NOTE that just to mount it to /home and NEVER choose to format it, otherwise everything we are doing is just of no damn use and become meaningless! this is the second KEY step, i.e. the single most IMPORTANT step for your goal towards "restorative installation"

c. back to the partition interface and go next, then follow every step as the fresh installation until it is finished and restart again.

6.restore the user profile

Now create the user account you had before, /home/user for instance.

su
useradd -d /home/user -G user -p ****** -s /bin/bash user

By skipping the -m option, a skeleton profile will not be copied to /home/user, and we are to keep using original data all and get it associated with this restored user account as before.

if you like to use GUI, in the following interface

Mind you, do NOT choose "Create home directory".

(Actually after the reinstallation, you DO need a user account other than root to login the system, so just do it right there. The way I was doing is to create a temporary user account and then delete it just because I wan habituated to think of the command line operation then! )

7. Post restoration - Site clearing !

Now that we get a reinstalled linux and everything kept there just like before the restoration, we can safely remove the boot item for our recovery task.

- edit /boot/grub/grub.conf and remove what we added right now.
- unmount /mnt/fcinstall
- remove the installation image and boot bzImage we copied to /home/ before if you like. Surely you can simply keep them there in case we need another reinstallation afterwards, hope you will not be of that bad luck though :)

Now, you just are going to enjoy everything you have before, including the Desktop, gnome-terminal settings, Mozilla bookmarks even visit history, application (like VirtualBox and Windows Xp virtual OS, etc.) and .....

[ Other Notes ]

From this text, written from my definite practice (which is not so smooth at the time though), we should suggest that in the future use of Linux :

Install new application as into the user partition (or a single other partition than that for holding the OS itself) as possible. The same principles is applicable for data placement. In order to keep this consistency, you have better to designated "--prefix=/home/user/..." if you are to install some extraneous packages and modules by building the source code.

In a word, the more spread you anchored your data, the less handy to do a restorative installation being described.

How to copy all including hidden files or directories using linux shell

While copying all stuff under a directory into another place, by

cp $SRC/* $DST

will fail to copy all the hidden file (prefixing with ., the dot) in the end.

A foolproof way to achieve this is to go sinuously :

cp $SRC/* $SRC/.* $DST

there will come up with prompt like :
cp: omitting directory `$SRC/.'
cp: omitting directory `$SRC/..'

just turn back on it. having got thing done.

Surfing Troves: Q&A for Oracle Distributed Database Application De...

Surfing Troves: Q&A for Oracle Distributed Database Application De...: "p { margin-bottom: 0.08in; }h2 { margin-bottom: 0.08in; }h2.western { font-family: 'Liberation Sans','Arial',sans-serif; font-size: 14pt; fo..."

Fedora Linux : can not see any icon on the desktop or the Gnome-Terminal configuration all grayed

This is simply because nautilus (Fedora file explorer/manager) failed to create the "Desktop" directory under $HOME of current the login user.

So to fix this, just manually create the directory by
mkdir -p $HOME/Desktop

logout and then log back in, both problems will get solved.

Thursday, December 30, 2010

Nvidia driver problems in Fedora Linux X86_64 - checking nvidia.ko failed or Segment fault in starting the drive module

1. for the first issue, however reinstalling the driver, updating by
nvidia-installer -a --update (internet access should be firstly ready)
or just copy the complained nvidia.ko file to the path that
the /etc/init.d/nvidia script searches, e.g.   /lib/modules/$(uname -r)/kernel/drivers/video/nvidia. All seems no effect !

try to find the driver release of fedora for nvidia display driver :

yum list "*nvidia*" leads to a multitude of stuff related to the driver

----------------------
akmod-nvidia.x86_64                                             1:195.36.31-1.fc12.7               rpmfusion-nonfree-updates
akmod-nvidia-173xx.x86_64                                       173.14.27-1.fc12.5                 rpmfusion-nonfree-updates
akmod-nvidia-96xx.x86_64                                        96.43.18-1.fc12.6                  rpmfusion-nonfree-updates
kmod-nvidia.x86_64                                              1:195.36.31-1.fc12.7               rpmfusion-nonfree-updates
kmod-nvidia-173xx.x86_64                                        173.14.27-1.fc12.5                 rpmfusion-nonfree-updates
kmod-nvidia-173xx-2.6.32.26-175.fc12.x86_64.x86_64              173.14.27-1.fc12.5                 rpmfusion-nonfree-updates
kmod-nvidia-2.6.31.12-174.2.17.fc12.x86_64.x86_64               190.53-1.fc12.3                    rpmfusion-nonfree-updates
kmod-nvidia-2.6.31.12-174.2.19.fc12.x86_64.x86_64               190.53-1.fc12.4                    rpmfusion-nonfree-updates
kmod-nvidia-2.6.31.12-174.2.22.fc12.x86_64.x86_64               190.53-1.fc12.5                    rpmfusion-nonfree-updates
kmod-nvidia-2.6.31.12-174.2.3.fc12.x86_64.x86_64                190.53-1.fc12.1                    rpmfusion-nonfree-updates
kmod-nvidia-2.6.31.5-127.fc12.x86_64.x86_64                     190.42-1.fc12.4                    rpmfusion-nonfree-updates
kmod-nvidia-2.6.31.6-145.fc12.x86_64.x86_64                     190.42-1.fc12.6                    rpmfusion-nonfree-updates
kmod-nvidia-2.6.31.6-162.fc12.x86_64.x86_64                     190.42-1.fc12.7                    rpmfusion-nonfree-updates
kmod-nvidia-2.6.31.6-166.fc12.x86_64.x86_64                     190.42-1.fc12.8                    rpmfusion-nonfree-updates
kmod-nvidia-2.6.31.9-174.fc12.x86_64.x86_64                     190.53-1.fc12                      rpmfusion-nonfree-updates
kmod-nvidia-2.6.32.10-90.fc12.x86_64.x86_64                     1:195.36.15-1.fc12.1               rpmfusion-nonfree-updates
kmod-nvidia-2.6.32.11-99.fc12.x86_64.x86_64                     1:195.36.15-1.fc12.2               rpmfusion-nonfree-updates
kmod-nvidia-2.6.32.12-114.fc12.x86_64.x86_64                    1:195.36.24-1.fc12.1               rpmfusion-nonfree-updates
kmod-nvidia-2.6.32.12-115.fc12.x86_64.x86_64                    1:195.36.24-1.fc12.2               rpmfusion-nonfree-updates
kmod-nvidia-2.6.32.14-127.fc12.x86_64.x86_64                    1:195.36.31-1.fc12                 rpmfusion-nonfree-updates
kmod-nvidia-2.6.32.16-141.fc12.x86_64.x86_64                    1:195.36.31-1.fc12.1               rpmfusion-nonfree-updates
kmod-nvidia-2.6.32.16-150.fc12.x86_64.x86_64                    1:195.36.31-1.fc12.2               rpmfusion-nonfree-updates
kmod-nvidia-2.6.32.19-163.fc12.x86_64.x86_64                    1:195.36.31-1.fc12.3               rpmfusion-nonfree-updates
kmod-nvidia-2.6.32.21-166.fc12.x86_64.x86_64                    1:195.36.31-1.fc12.4               rpmfusion-nonfree-updates
kmod-nvidia-2.6.32.23-170.fc12.x86_64.x86_64                    1:195.36.31-1.fc12.6               rpmfusion-nonfree-updates
kmod-nvidia-2.6.32.26-175.fc12.x86_64.x86_64                    1:195.36.31-1.fc12.7               rpmfusion-nonfree-updates
kmod-nvidia-2.6.32.8-58.fc12.x86_64.x86_64                      190.53-1.fc12.6                    rpmfusion-nonfree-updates
kmod-nvidia-2.6.32.9-70.fc12.x86_64.x86_64                      1:195.36.15-1.fc12                 rpmfusion-nonfree-update
.................

just use the correct version for current kernel, for example

yum -y install kmod-nvidia-2.6.32.21-166.fc12.x86_64.x86_64

then go to /etc/init.d/, ./nvidia status, Got it !

2. when the problem got resolved as above, there comes another :
During the start-up, it reports as :
Enabling the nvidia driver: /etc/rc.d/init.d/functions: line $LINENO Segmentation fault "$@" (core dumped)....

For this one, Leight123Linux 's cure is really great, simple but definitely efficacious :

mv /etc/X11/xorg.conf /etc/X11/xorg.conf.broken
nvidia-config-display disable
nvidia-config-display enable

see the source I consulted to :
http://forums.fedoraforum.org/archive/index.php/t-247152.html

Just this simple, the nasty problem got fixed up!

Thanks to Leigh123linux again for this useful tip!

[ For a complete guide for installing Nvidia Driver on Fedora Linux, here is a good reference at http://www.if-not-true-then-false.com/2010/fedora-14-nvidia-drivers-install-guide-disable-nouveau-driver/ ]

Fedora Linux : Always got wrong IP configured

while the network configuration in the ifcfg-eth0 is as follows:

IPADDR=x.x.31.231
BROADCAST=x.255.255.255
NETWORK=x.x.31.0
NETMASK=255.255.255.0
GATEWAY=x.x.31.1

after /sbin/ifup eth0

/sbin/ifconfig eth0 displays a magic configuration as :

eth0      Link encap:Ethernet HWaddr xxxxxx
            inet addr:x.x.35.200 Bcast:x.x.35.255 Mask:255.255.255.128
   .........................

fiddling over and over (ifdown then ifup, and also including to restart network and NetManager services), just no damn a use! The system always applies this weird IP configuration !!

Finally, the bug got found by just "grep "x.x.35.200" /etc/sysconfig/network-scripts/* ", there is another file
ifcfg-reference there that contains this surprising configuration above.

Move this extraneous file, either deleting or moving to other directory, the problem got rid of !

Linux : Access network service in Single user mode

1. Enter the Level 1 - Single User Mode
In the grub boot memu, select the entry for the OS you want to start up, press "e" to edit :
Just remove the tailing "rhgb quiet" and append " single" instead;
then press "b" to enter the single user mode.

2. In order to access the network service
most of the time, the reason why you might want to enter this level 1 mode is probably your failure to start up the Linux normally so you would want to use networking for downloading something, thus you should need network access, which is disabled by default in Level 1, single user mode

a. check the network device configuration to see if it is right there and the item agrees with your need or desire.
e.g. cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
NETWORK=
NETMASK=
IPADDR=
GATEWAY=
USERCTL=no

b. then start network service by
/sbin/service network start

c. if you run into problems like "Temporary failure in name resolution..." while you are going to download from a website, you should check the /etc/resolv.conf to see if there places at least one nameserver and the server is really reachable. if not, you should add like

nameserver x.x.x.x
nameserver x.x.x.x
if you do not know what to fill here after "nameserver", you can refer to other machine within the same domain as yours current which is available for network access.

(Sometimes, when you restarted the NetworkManager service, this name resolution configuration might also be cleared, then you will need to edit like above too).

d. to verify if it got fixed, try something like wget
wget www.google.com, for instance, it now works well if you can get the index.html from this site.

Wednesday, December 29, 2010

Surfing Troves: Can not find the cairo library or version is lower...

Surfing Troves: Can not find the cairo library or version is lower...: "One more prerequisite for GTK+, which might be complaining the lower version than required or simply loss of it: try to reinstall in the..."

Tuesday, December 28, 2010

Surfing Troves: Can not find the atk library or version is lower t...

Surfing Troves: Can not find the atk library or version is lower t...: "Yet another prerequisite for GTK+, which might be complaining the lower version than required or simply loss of it: 1. retrieve package per..."

Ordeal with Installation of GTK+-2.4 in Linux Enviroment ( Fedora 13 & x86 64bit )

1.
go ftp://ftp.gtk.org/pub/gtk/v2.4/ :

wget ftp://ftp.gtk.org/pub/gtk/v2.4/glib-2.4.7.tar.bz2

bunzip glib-2.4.7.tar.bz2 && tar xvf glib-2.4.7.tar.bz2

cd glib-2.4.7.tar.bz2 && ./configure && make && make install

pkg-config --modversion glib-2.0
2.4.7

2.
wget ftp://ftp.gtk.org/pub/gtk/v2.4/pango-1.4.1.tar.bz2

same steps to install pango 1.4.1 as above

but, OOPS:

*** 'pkg-config --modversion glib-2.0' returned 2.4.7, but GLIB (2.26.1)
*** was found! If pkg-config was correct, then it is best
*** to remove the old version of GLib. You may also be able to fix the error
*** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing
*** /etc/ld.so.conf. Make sure you have run ldconfig if that is
*** required on your system.
*** If pkg-config was wrong, set the environment variable PKG_CONFIG_PATH
*** to point to the correct configuration files
no
configure: error:
*** Glib 2.4.0 or better is required. The latest version of
*** Glib is always available from ftp://ftp.gtk.org/.

Even clean up all other occurrences of glib-2.0 as directories and keep only one, the problem is adamant !

since I installed glib2.26.1 before, so I tried with "cd glib2.26.1 && make uninstall", seems effective a bit!

*** 'pkg-config --modversion glib-2.0' returned 2.4.7, but GLIB (2.27.4)
*** was found! If pkg-config was correct, then it is best
*** to remove the old version of GLib. You may also be able to fix the error
*** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing
*** /etc/ld.so.conf. Make sure you have run ldconfig if that is
*** required on your system.
*** If pkg-config was wrong, set the environment variable PKG_CONFIG_PATH
*** to point to the correct configuration files
no
configure: error:
*** Glib 2.4.0 or better is required. The latest version of
*** Glib is always available from ftp://ftp.gtk.org/.

actually I have also installed ever glib2.27.4 before 2.26.1.........., it appears every building installation leaves certain trash or something somewhere!

So, follow the same trick : cd glib2.27.4 && make uninstall

Gosh, not that lucky again! just the same gnats!

Desperately, find / -name "*glib-2.0*" -delete !! (a bit of daunting admittedly.. but might it be worth taking risk)

Then get back to glib2.4.7 and "
make clean &&
make uninstall &&
./configure
make
make install

still no joy :

checking for GLIB - version >= 2.4.0... no
*** Could not run GLIB test program, checking why...
*** The test program compiled, but did not run. This usually means
*** that the run-time linker is not finding GLIB or finding the wrong
*** version of GLIB. If it is not finding GLIB, you'll need to set your
*** LD_LIBRARY_PATH environment variable, or edit /etc/ld.so.conf to point
*** to the installed location Also, make sure you have run ldconfig if that
*** is required on your system
***
*** If you have an old version installed, it is best to remove it, although
*** you may also be able to get things to work by modifying LD_LIBRARY_PATH
configure: error:
*** Glib 2.4.0 or better is required. The latest version of
*** Glib is always available from ftp://ftp.gtk.org/.

--------------------- how GLIBC and GTK (or merely this pango?) makes bitter stuff ---------------------------------------

Now it sounds that the version retrieved by ./configure (of pango) as the number in " but GLIB (2.27.4)...." stems from dynamic library libglib-2.0.so (if it is a symblic link, then its target).

Following this clue, try to place correct version of .so (that produced by glibc-2.4.7, say) into where the "pkg-config --libs glib-2.0" tells !

It is weird however, that the .so glib2.4.7 produces is always WRONG! even make many other dependant like yum disabled!

Continuously, also tried with glib2.4.8 forwardly and glib2.4.1 backwardly, both having the same problem --- producing dynamic libraries (.so) that is not recognizable by all its dependants that I know.

succumbed to this nasty for now!

------------------------------ Follow up----------------------------------------

=>Later, tried with even much higher version - GLib 2.9.6, nothing better in the end!

=>Later still, count on the latest version of GTK+ 2.91 up to Dec 22, 2010, it got, incredibly blocked by:
...
Requested 'glib-2.0 >= 2.27.5' but version of GLib is 2.9.6
...

this is awfully another buffoon which is out of my expectation:
should 2.9.6 be a lower version than 2.27.5?
is it reasonable? why...

--- maybe only the GTK+ developer can tell the secret.

Can not find the gdk-pixbuf library or version is lower than required

One more, maybe last in the nasty complaining list for building GTK+-2.22.1, prerequisite for GTK+, which might be complaining the lower version than required or simply loss of it:

1. yum -y reinstall gdk-pixbuf-devel.x86_64 gdk-pixbuf.x86_64
oops, no luck this time, ./configure of GTK still grouses there for missing it (on some platforms, this reintallation could only get the 0.22.0 version, for instance)

( if it wors ok now for you, stop here and congrutulations to you!)

2. download and built on source package

But gdk-pixelbuf-2.0 can NOT be found, how repulsively this costly trivial steps end like this!

Finally, it is a conclusion: you should build gtk-2.4, where gdk-pixbuf-2.0 will be included inside!!

bewildered definitely, what else could we do but to follow it ?!

Open another post for the GTK+ installation/upgrading in :
http://surfingtroves.blogspot.com/2010/12/ordeal-with-installation-of-gtk-24-in.html

Can not find the cairo library or version is lower than required

One more prerequisite for GTK+, which might be complaining the lower version than required or simply loss of it:

try to reinstall in the first place:

yum -y reinstall cairo-devel.x86_64 cairo.x86_64

and the cairo dependencies,
yum -y reinstall pixman-devel.x86_64 pixman.x86_64
yum -y reinstall freetype.x86_64 freetype-devel.x86_64
yum -y reinstall libpng.x86_64 libpng-devel.x86_64
yum -y reinstall libXrender.x86_64 libXrender-devel.x86_64

yum -y reinstall libX11-devel.x86_64 libX11.x86_64
yum -y reinstall libXau libXau-devel

for things might be lost:
yum -y install libxcb libxcb-devel

oh, my goodness, it works at last now:

pkg-config --modversion cairo
1.8.8

beaten it!

Can not find the pango library or version is lower than required

Another prerequisite for GTK+, which might be complaining the lower version than required or simply loss of it:

1. check the current version
pkg-config --modversion pango

Package pango was not found in the pkg-config search path.
Perhaps you should add the directory containing `pango.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pango' found

2. try to locate the .pc file
locate pango.pc
/usr/local/lib/pkgconfig/pango.pc

3. add the containing path into PKG_CONFIG_PATH
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig

4. check it again
pkg-config --modversion pango
1.28.3

done!

or if failed at locating the .pc, just download the source package from http://www.gtk.org/download-linux.html :
./configure --prefix=$path_you_like && make && make install

then simply follow the similar steps above in the event of newborn problems

Can not find the atk library or version is lower than required

Yet another prerequisite for GTK+, which might be complaining the lower version than required or simply loss of it:

1. retrieve package pertaining to atk
yum list "*atk*"
Loaded plugins: presto, refresh-packagekit
Installed Packages
atk.i686                                                                            1.28.0-1.fc12                                                             @fedora
atk.x86_64                                                                          1.28.0-1.fc12                                                             @fedora
atk-devel.x86_64                                                                    1.28.0-1.fc12                                                             @fedora
ruby-atk.x86_64                                                                     0.19.3-3.fc12                                                             @fedora
Available Packages
atk-devel.i686                                                                      1.28.0-1.fc12                                                             fedora
maatkit.noarch                                                                      5014-1.fc12                                                               updates
mingw32-atk.noarch                                                                  1.27.90-1.fc12                                                            fedora
mingw32-atk-static.noarch                                                           1.27.90-1.fc12                                                            fedora
ruby-atk.x86_64                                                                     0.19.4-1.fc12                                                             updates
ruby-atk-devel.i686                                                                 0.19.4-1.fc12                                                             updates
ruby-atk-devel.x86_64                                                               0.19.4-1.fc12                                                             updates

2. reinstall the needed

yum -y reinstall atk.x86_64 atk-devel.x86_64

3. check it to verify
pkg-config --modversion atk
1.28.0

got it now.

-----------------------------------------------------------------------------------------------------------------

If the yumdb does contain the atk with required version, just download from
http://ftp.gnome.org/pub/gnome/sources/atk/1.32/atk-1.32.0.tar.gz, and following the simplest building steps : ./configure && make && make install

Acrobat reader 9.0 failed to load libraries in the Linux run

Having run into the nasty problem with acrobat reader in the Linux (Fedora 13 64bit):

/opt/Adobe/Reader9/Reader/intellinux/bin/acroread: error while loading shared libraries: libfontconfig.so.1: wrong ELF class: ELFCLASS64

it says I should find a 64 bit version of libfontconfig library?

Solution simple but efficacious - reinstall the 64 bit version :

yum list uninstalled "*fontconfig*"
---
# yum list uninstall "*fontconfig*"
Loaded plugins: presto, refresh-packagekit
Available Packages
fontconfig.i686                                                                     2.8.0-1.fc12                                                             @updates
fontconfig.x86_64                                                                   2.8.0-1.fc12                                                             @updates
fontconfig-devel.x86_64                                                             2.8.0-1.fc12                                                             @updates
fontconfig-devel.i686                                                               2.8.0-1.fc12                                                             updates
mingw32-fontconfig.noarch                                                           2.6.0-10.fc12                                                            fedora

should it be the fontconfig*.x86_64?

yum -y install fontconfig.x86_64 fontconfig-devel.x86_64

ok, now take another try with acroread, actually it started up but seemingly unpleasantly. Here is the complaints:

(acroread:15712): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(acroread:15712): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(acroread:15712): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(acroread:15712): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(acroread:15712): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(acroread:15712): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(acroread:15712): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(acroread:15712): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(acroread:15712): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(acroread:15712): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(acroread:15712): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(acroread:15712): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(acroread:15712): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(acroread:15712): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(acroread:15712): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(acroread:15712): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(acroread:15712): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",
Gtk-Message: Failed to load module "atk-bridge": libatk-bridge.so: wrong ELF class: ELFCLASS64
Gtk-Message: Failed to load module "pk-gtk-module": libpk-gtk-module.so: wrong ELF class: ELFCLASS64
Gtk-Message: Failed to load module "canberra-gtk-module": libcanberra-gtk-module.so: wrong ELF class: ELFCLASS64

Linux / Fedora 64 - upgraded package and library not work or recognized

while upgrading GTK+ by building the package from the source code from
http://www.gtk.org/download-linux.html, following the simplest steps to build gtk+-2.22.1:

./configure even failed by dumping :
configure: error: Package requirements (glib-2.0 >= 2.25.10    atk >= 1.29.2    pango >= 1.20    cairo >= 1.6    gdk-pixbuf-2.0 >= 2.21.0) were not met

and grouching that current glib-2.0 version is 2.22.5, lower than the needed.

So, download GLib2.26 from the same site above, and smoothly brought off the building process, everything seems ok.

When resume the ./configure for gtk+ however, it sticks to the same complaints !

------------   upgrade finished right now is not recognized !

thumb around online discussion and blogs, finally found out the culprit - the path where the upgrade got installed is inconsistent with what pkg-config searches by default.

pkg-config       --modversion glib-2.0
2.22.5

perusing the man page of pkg-config to get know the cause and the solution :

REMOVE the old glibconfig.h before "make install" for the upgrade of glib-2.0, for instance:
rm -rf /usr/lib64/glib-2.0/include/glibconfig.h

get back to glib2.26.1, cd the source path, perform "make install" (since we have done "make" before and not clean up the objects by "make clean". otherwise, should start over from "make" )

and again, pkg-config       --modversion glib-2.0
2.26.1

all right, find it!

Wednesday, December 22, 2010

Compiling OpenVRML - error : cannot find -lltdl

This is because of loss of the static library libltdl.a, which is one of the output if you install libtool

To make up, simply download the GNU libtool from official site
http://ftp.gnu.org/gnu/libtool/libtool-2.4.tar.gz

unpack, and go no special steps as
./configure && make && make install

then as default, libltdl.a should be placed at /usr/local/lib.

get back to openVRML,

make clean
( do not omit this, or you will be bothered with nasty even weird link error like " undefined reference : openvrml::dl::close...!)
make & make install

done!

Tuesday, December 21, 2010

Building installation of FreeWRL for Fedora 12/13/14 on X86_64

The official site of FreeWRL only provides installation guide for Ubuntu in the range of Linux series. While different OS has different tool kit and features (esp. installed packages or library requirements),
the instruction can not simply lead you to success in installation of FreeWRL for fedora.

Here to go:

1. Started from http://freewrl.sourceforge.net/install_Linux.html

the guided steps should be:

cd freewrl/freex3d
sh autogen.sh /bin/bash
./configure --with-target=motif --prefix=/usr --with-fontsdir=/usr/share/fonts/bitstream-vera
make
make install

But you might most possibly get stunt before make.

In order to generate ./configure, "sh autogen.sh" will constantly complain under Fedora like :
Remaining args: /bin/bash
Platform: Linux
Please install the ttf-bitstream-vera font package.
and to do nothing further, thus we can not go to ./configure since it was blocked to produce.

open the autogen.sh it can be found that this script is mostly catering for Debian among Linux platforms:
case $platform in
    Linux)
        echo "Platform: Linux"

if [ -f /etc/debian_version ] ; then
            echo "Distribution: Debian / Ubuntu"
            if [ -d /usr/share/fonts/truetype/ttf-bitstream-vera ] ; then
                fontsdir=/usr/share/fonts/truetype/ttf-bitstream-vera
            fi
        else
            echo "Please install the ttf-bitstream-vera font package."
            exit 0
        fi

In a coarse way, just forcibly comment out the "exit 0" line. Then run the script back again.

It can work and spawn ./configure !
then Here we go!

2. Get the source code from CVS so that I touch the latest. Might it be unstable like the release packages, but most likely it is okay.

cvs -z3 -d:pserver:anonymous@freewrl.cvs.sourceforge.net:/cvsroot/freewrl checkout -P freewrl

Sure, You can also simple pick source code releases from the project page of FreeWRL on sourceForge

at http://sourceforge.net/projects/freewrl/files/freewrl-linux/1.22/freewrl-1.22.10.tar.bz2/download

3. Install Font stuffs that FreeWRL needs

a. FreeType devel component

yum -y install freetype-devel

b. ttf-bitstream-vera TrueType font

yum -y install bitstream-vera-fonts-1.10-0.fdr.14.noarch.rpm

Not done with this gnat yet, for sure should get the real thing, font files.

wget http://ftp.gnome.org/pub/GNOME/sources/ttf-bitstream-vera/1.10/ttf-bitstream-vera-1.10.zip

unpack it, should see the 10 font files inside

mkdir -p /usr/share/fonts/ttf-bitstream-vera/

cp ttf-bitstream-vera-1.10/*.ttf /usr/share/fonts/ttf-bitstream-vera/

then, update the font cache with this new font

fc-cache -f -v /usr/share/fonts/ttf-bitstream-vera/

again, flush the cache

fc-cache -f -v

4. other miscellaneous components, stumped with them during ./configure with freeWRL

a. the expat XML Parser

  yum -y install expat-devel

  yum -y install expat

b. the Mozilla XUL (XML User Interface Language) runtime backend
  yum -y install xulrunner-devel

c.Javascript Engine and the seamonkey internet suite component

  yum -y install rhino
  yum -y install seamonkey

d. X window libraries

yum -y install libXmu-devel
yum -y install libXaw-devel

e. the  Enlightenment Foundation Libraries (EFL) graphical library

yum -y install imlib2

if this is not sufficient to make the ./configure  aware of imlib2, play the trump:

yum -y install imlib2.x86_64 imlib2-devel.x86_64

5. install openMotif

(if you succeeded by "locate "Xm/Xm.h", skip this step)

yum -y install openmotif

yum -y install openmotif-devel

yum install openmotif-2.3.3-1.fc12.x86_64.rpm (for my X86_64 machine)

if this gives no cure, then  erase it

yum -y erase openmotif

and reinstalled.

Download and build it with source code, it might not be straightforward as imagined.

(see for detail  http://surfingtroves.blogspot.com/2010/12/compiling-openmotif-under-fedora-13.html )

6. install OpenGL extension : GLEW

yum -y install glew

yum -y install glew-devel

7. get back to freeWRL

cd freewrl/freex3d

./configure --with-target=motif --prefix=/usr --with-fontsdir=/usr/share/fonts/ttf-bitstream-vera

make

make install

8. set LD_LIBRARY_PATH, make sure it includes where the dynamic libraries libFreeWRL.so.*

are situated.

provided they are placed by "make install" under /usr/lib, then

export  LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH

9. almost get it, verify by testing

cd freewrl/freewrl/tests

freewrl *.wrl (choose any of them to test)

10. see the graphical things? all well done!

(for the stuff above, http://freewrl.sourceforge.net/TomSmithCore13.html was referred!)

* Other pages to refer :

http://www.gnome.org/fonts/

http://www.cb1.com/~john/notes/fedora-font-install.html

(should any more questions, please post as comments below, will check it and try to solve it.)

------------------------------------------------------------
[ Supplement ]

Some others reported that during the "make", still more problems arise like :

/usr/include/xulrunner-sdk-1.9.2/expat.h:530:43: warning: type defaults to 'int' in declaration of 'XML_Char'
/usr/include/xulrunner-sdk-1.9.2/expat.h:530:52: error: expected ';', ',' or ')' before '*' token
/usr/include/xulrunner-sdk-1.9.2/expat.h:535:23: error: expected declaration specifiers or '...' before 'XML_StartElementHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:536:23: error: expected declaration specifiers or '...' before 'XML_EndElementHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:540:28: error: expected declaration specifiers or '...' before 'XML_StartElementHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:544:26: error: expected declaration specifiers or '...' before 'XML_EndElementHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:548:29: error: expected declaration specifiers or '...' before 'XML_CharacterDataHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:552:37: error: expected declaration specifiers or '...' before 'XML_ProcessingInstructionHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:555:23: error: expected declaration specifiers or '...' before 'XML_CommentHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:576:23: error: expected declaration specifiers or '...' before 'XML_DefaultHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:584:29: error: expected declaration specifiers or '...' before 'XML_DefaultHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:588:27: error: expected declaration specifiers or '...' before 'XML_StartDoctypeDeclHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:593:32: error: expected declaration specifiers or '...' before 'XML_StartDoctypeDeclHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:601:34: error: expected declaration specifiers or '...' before 'XML_UnparsedEntityDeclHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:605:28: error: expected declaration specifiers or '...' before 'XML_NotationDeclHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:609:29: error: expected declaration specifiers or '...' before 'XML_StartNamespaceDeclHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:610:29: error: expected declaration specifiers or '...' before 'XML_EndNamespaceDeclHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:614:34: error: expected declaration specifiers or '...' before 'XML_StartNamespaceDeclHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:618:32: error: expected declaration specifiers or '...' before 'XML_EndNamespaceDeclHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:626:33: error: expected declaration specifiers or '...' before 'XML_ExternalEntityRefHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:638:29: error: expected declaration specifiers or '...' before 'XML_SkippedEntityHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:642:31: error: expected declaration specifiers or '...' before 'XML_UnknownEncodingHandler'
In file included from x3d_parser/X3DParser.c:57:0:
/usr/include/xulrunner-sdk-1.9.2/expat.h:683:42: warning: type defaults to 'int' in declaration of 'XML_Char'
/usr/include/xulrunner-sdk-1.9.2/expat.h:683:51: error: expected ';', ',' or ')' before '*' token
In file included from x3d_parser/X3DParser.c:57:0:
/usr/include/xulrunner-sdk-1.9.2/expat.h:723:38: warning: type defaults to 'int' in declaration of 'XML_Char'
/usr/include/xulrunner-sdk-1.9.2/expat.h:723:47: error: expected ';', ',' or ')' before '*' token
/usr/include/xulrunner-sdk-1.9.2/expat.h:725:17: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
In file included from x3d_parser/X3DParser.c:57:0:
/usr/include/xulrunner-sdk-1.9.2/expat.h:850:38: warning: type defaults to 'int' in declaration of 'XML_Char'
/usr/include/xulrunner-sdk-1.9.2/expat.h:850:47: error: expected ';', ',' or ')' before '*' token
In file included from x3d_parser/X3DParser.c:57:0:
/usr/include/xulrunner-sdk-1.9.2/expat.h:957:18: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
/usr/include/xulrunner-sdk-1.9.2/expat.h:961:18: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
/usr/include/xulrunner-sdk-1.9.2/expat.h:992:19: error: expected ':', ',', ';', '}' or '__attribute__' before '*' token
In file included from x3d_parser/X3DParser.c:57:0:
/usr/include/xulrunner-sdk-1.9.2/expat.h:1010:16: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
x3d_parser/X3DParser.c: In function 'getRoutingInfo':
x3d_parser/X3DParser.c:440:10: warning: assignment from incompatible pointer type
x3d_parser/X3DParser.c:444:10: warning: assignment from incompatible pointer type
x3d_parser/X3DParser.c:448:10: warning: assignment from incompatible pointer type
x3d_parser/X3DParser.c: In function 'saveAttributes':
x3d_parser/X3DParser.c:1277:54: warning: assignment from incompatible pointer type
x3d_parser/X3DParser.c:1279:53: warning: assignment from incompatible pointer type
x3d_parser/X3DParser.c:1281:54: warning: assignment from incompatible pointer type
x3d_parser/X3DParser.c: In function 'initializeX3DParser':
x3d_parser/X3DParser.c:1754:3: warning: implicit declaration of function 'XML_ParserCreate'
x3d_parser/X3DParser.c:1754:36: warning: assignment makes pointer from integer without a cast
x3d_parser/X3DParser.c:1755:3: error: too many arguments to function 'XML_SetElementHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:534:1: note: declared here
x3d_parser/X3DParser.c:1757:3: error: too many arguments to function 'XML_SetDefaultHandler'
/usr/include/xulrunner-sdk-1.9.2/expat.h:575:1: note: declared here
x3d_parser/X3DParser.c: In function 'X3DParse':
x3d_parser/X3DParser.c:1824:4: warning: implicit declaration of function 'XML_ErrorString'
x3d_parser/X3DParser.c:1825:4: warning: format '%s' expects type 'char *', but argument 3 has type 'int'
make[3]: *** [x3d_parser/X3DParser.lo] Error 1
make[3]: Leaving directory `/root/freewrl/freex3d/src/lib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/root/freewrl/freex3d/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/freewrl/freex3d'
make: *** [all] Error 2

For the solutions, istakenv's suggestion is really simple but great. Since it is in the comment area which is not always presented on the page, I copied here for your ease of reading:

There is an issue with the way expat and xulrunner are installed on most
linux systems. FreeWRL needs to use the system-wide expat (installed to
/usr/include), whereas xulrunner bundles an expat and, due to the way that
gcc -always- puts priority on "-I/path/to/include" arguments over
/usr/include, gcc always ends up compiling with the expat.h bundled in
xulrunner instead of /usr/include/expat.h ... The fix for this is as
follows:

mkdir /tmp/include
cp /usr/include/expat*.h /tmp/include
cd /path/to/freewrl
./configure --with-expat=/tmp

(quoted from http://sourceforge.net/tracker/index.php?func=detail&aid=3061173&group_id=9120&atid=109120 )

Compiling Openmotif under Fedora 13 - error: X11/bitmaps/gray: No such file or directory

Stumped with the nag for long when I was compiling OpenMotif 2.3.3

Download package at :
http://www.motifzone.net/files/public_downloads/openmotif/2.3/2.3.3/openmotif-2.3.3.tar.gz

[root@cslab206 openmotif-2.3.3]# locate "X11/bitmaps"
/usr/include/X11/bitmaps
/usr/include/X11/bitmaps/xm_error
/usr/include/X11/bitmaps/xm_hour16
/usr/include/X11/bitmaps/xm_hour16m
/usr/include/X11/bitmaps/xm_hour32
/usr/include/X11/bitmaps/xm_hour32m
/usr/include/X11/bitmaps/xm_information
/usr/include/X11/bitmaps/xm_noenter16
/usr/include/X11/bitmaps/xm_noenter16m
/usr/include/X11/bitmaps/xm_noenter32
/usr/include/X11/bitmaps/xm_noenter32m
/usr/include/X11/bitmaps/xm_question
/usr/include/X11/bitmaps/xm_warning
/usr/include/X11/bitmaps/xm_working

or directly looking into /usr/include/X11/bitmaps, actually the "gray" lost there.

Then, google around and got tips from some guys who cued that I should follow by
" yum -y install xbase"

Still no joy.

Try searching in the yumdb:
[root@cslab206 openmotif-2.3.3]# yum list "*bitmap*"
Loaded plugins: presto, refresh-packagekit
Installed Packages
bitmap-fonts.noarch                                               0.3-9.fc12                                           @anaconda-InstallationRepo-200911081904.x86_64
wqy-bitmap-fonts.noarch                                           0.9.9-11.fc12                                        @fedora
Available Packages
bitmap.x86_64                                                     1.0.3-6.fc12                                         fedora
bitmap-cjk-fonts.noarch                                           0.3-9.fc12                                           fedora
bitmap-fonts-common.noarch                                        0.3-9.fc12                                           fedora                                        xorg-x11-xbitmaps.x86_64                                          1.0.1-9.fc12                                         @fedora

japanese-bitmap-fonts.noarch                                      0.20080710-8.fc12                                    fedora
mona-bitmap-fonts.noarch                                          2.90-9.fc12                                          fedora
nethack-bitmap-fonts.noarch                                       3.4.3-23.fc12                                        fedora
nethack-bitmap-fonts-core.noarch                                  3.4.3-23.fc12                                        fedora
wqy-bitmap-fonts.noarch                                           1.0.0-0.1.rc1.fc12                                   updates

yum -y install xorg-x11-xbitmaps

back to openmotif,

make, make install, works well!

Monday, December 20, 2010

Integral transform

Mathematical notation aside, the motivation behind integral transforms is easy to understand. There are many classes of problems that are difficult to solve—or at least quite unwieldy algebraically—in their original representations. An integral transform "maps" an equation from its original "domain" into another domain. Manipulating and solving the equation in the target domain can be much easier than manipulation and solution in the original domain. The solution is then mapped back to the original domain with the inverse of the integral transform.

Table of integral transforms
Transform	Symbol	$K$	t₁	t₂	$K - 1$	u₁	u₂
Fourier transform	$\mathcal{F}$	$\frac{e^{-iut}}{\sqrt{2 \pi}}$	$-\infty\,$	$\infty\,$	$\frac{e^{+iut}}{\sqrt{2 \pi}}$	$-\infty\,$	$\infty\,$
Fourier sine transform	$\mathcal{F}_s$	$\frac{\sqrt{2}\sin{(ut)}}{\sqrt{\pi}}$	$0\,$	$\infty$	$\frac{\sqrt{2}\sin{(ut)}}{\sqrt{\pi}}$	$0\,$	$\infty$
Fourier cosine transform	$\mathcal{F}_c$	$\frac{\sqrt{2}\cos{(ut)}}{\sqrt{\pi}}$	$0\,$	$\infty$	$\frac{\sqrt{2}\cos{(ut)}}{\sqrt{\pi}}$	$0\,$	$\infty$
Hartley transform	$\mathcal{H}$	$\frac{\cos(ut)+\sin(ut)}{\sqrt{2 \pi}}$	$-\infty\,$	$\infty\,$	$\frac{\cos(ut)+\sin(ut)}{\sqrt{2 \pi}}$	$-\infty\,$	$\infty\,$
Mellin transform	$\mathcal{M}$	$t^{u-1}\,$	$0\,$	$\infty\,$	$\frac{t^{-u}}{2\pi i}\,$	$c\!-\!i\infty$	$c\!+\!i\infty$
Two-sided Laplace transform	$\mathcal{B}$	$e^{-ut}\,$	$-\infty\,$	$\infty\,$	$\frac{e^{+ut}}{2\pi i}$	$c\!-\!i\infty$	$c\!+\!i\infty$
Laplace transform	$\mathcal{L}$	$e^{-ut}\,$	$0\,$	$\infty\,$	$\frac{e^{+ut}}{2\pi i}$	$c\!-\!i\infty$	$c\!+\!i\infty$
Weierstrass transform	$\mathcal{W}$	$\frac{e^{-(u-t)^2/4}}{\sqrt{4\pi}}\,$	$-\infty\,$	$\infty\,$	$\frac{e^{+(u-t)^2/4}}{i\sqrt{4\pi}}$	$c\!-\!i\infty$	$c\!+\!i\infty$
Hankel transform		$t\,J_\nu(ut)$	$0\,$	$\infty\,$	$u\,J_\nu(ut)$	$0\,$	$\infty\,$
Abel transform		$\frac{2t}{\sqrt{t^2-u^2}}$	$u\,$	$\infty\,$	$\frac{-1}{\pi\sqrt{u^2\!-\!t^2}}\frac{d}{du}$	$t\,$	$\infty\,$
Hilbert transform	$\mathcal{H}il$	$\frac{1}{\pi}\frac{1}{u-t}$	$-\infty\,$	$\infty\,$	$\frac{1}{\pi}\frac{1}{u-t}$	$-\infty\,$	$\infty\,$
Poisson kernel		$\frac{1-r^2}{1-2r\cos\theta +r^2}$	$0\,$	$2\pi\,$
Identity transform		$\delta (u-t)\,$	$t_1<u\,$	$t_2>u\,$	$\delta (t-u)\,$	$u_1\!<\!t$	$u_2\!>\!t$

In the limits of integration for the inverse transform, c is a constant which depends on the nature of the transform function. For example, for the one and two-sided Laplace transform, c must be greater than the largest real part of the zeroes of the transform function.

Although the properties of integral transforms vary widely, they have some properties in common. For example, every integral transform is a linear operator, since the integral is a linear operator, and in fact if the kernel is allowed to be a generalized function then all linear operators are integral transforms (a properly formulated version of this statement is the Schwartz kernel theorem).
The general theory of such integral equations is known as Fredholm theory. In this theory, the kernel is understood to be a compact operator acting on a Banach space of functions. Depending on the situation, the kernel is then variously referred to as the Fredholm operator, the nuclear operator or the Fredholm kernel.

Surfing Troves

Welcome

Disclaimer