|
osdir.com mailing list archive |
|
Subject: Re: sfs on ia64 with gcc 3.2 - msg#00036List: file-systems.sfs.general>> From: Jaakko Niemi <liiwi@xxxxxxxxxxxxx> >> Date: Sun, 23 Feb 2003 10:27:42 +0200 >> >> >> Mailing-List: contact sfs-help@xxxxxxxxxx; run by ezmlm >> >> From: Jaakko Niemi <liiwi@xxxxxxxxxxxxx> >> >> >> >> On itree.h, around line 89, there is: >> >> >> >> #define eos ((int) &(((T *) 0)->*field).p) >> >> >> >> This does not work on 64-bit archs where int is 32-bit and >> >> pointers 64-bit. Pointer gets cut and bad things happen. >> >> >> >> I'm not sure if there is better solution than casting that >> >> to long instead of int. >> > >> > This should be fine. SFS compiles and runs fine on the alpha, which >> > also has 64-bit pointers and 32-bit ints. Even though pointers are >> > 64-bits, the size of data structure T is not going to be more than 2 >> > Gigabytes (or else SFS wouldn't compile for 32-bit architectures). >> >> You mean it's ok to use long there? > > I'm afraid it's been so long that I've forgotten the context of this > message. However, the code as written (with int) should be just > fine. There must be some other problem. Maybe you could try: > > #define eos reinterpret_cast<int> (&(((T *) 0)->*field).p) > > What is the compiler error? Just a warning about the pointer getting cut: itree.h:125: warning: cast from pointer to integer of different size >> >> Problem here is that gcc does not grok c++ libs. So far, I haven't been >> >> able >> >> to come with cleaner solution than renaming funmount.c to funmount.cc. >> >> >> >> Weird thing is that this did not come up earlier. >> >> >> >> Comments? >> > >> > Strange. Are you saying this is only a problem for funmount, and not >> > for anything else? >> >> funmount and agent/dirsearch are the problematic ones. > > Again, the details are fuzzy because I don't remember the email. > dirsearch.c is a C program, which shouldn't even need C++ libraries. Here's beginning of the error: > gcc-3.2 -g -O2 -Wall -o .libs/funmount funmount.o > ../sfsmisc/.libs/libsfsmisc.so -lresolv -lnsl ../svc/.libs/libsvc.so -lresolv > -lnsl > ../crypt/.libs/libsfscrypt.so -lresolv -lnsl ../arpc/.libs/libarpc.so > -lresolv -lnsl ../async/.libs/libasync.so -lresolv -lnsl usr > lib/libgmp.so -lresolv -lnsl -Wl,--rpath -Wl,/usr/local/lib/sfs-0.6 > ../svc/.libs/libsvc.so: undefined reference to `typeinfo for bool' > ../sfsmisc/.libs/libsfsmisc.so: undefined reference to `vtable for > __cxxabiv1::__si_class_type_info' So, looks like gcc 3.2 does not like c++ libs being included. >> > Have you tried compiling with static as well as shared libraries? >> >> This happens only with shared libs. > > So maybe libtool on the ia64 just doesn't support shared libraries > yet. This would not be surprising, as getting C++ to work is a bit > trickier, and in theory not supported until the next full version > number of libtool (the so-called multi-lingual branch). Sorry if I was unclear, this happens on all archs. With debian packages, as a workaround I moved the files to .cc, so g++ is used to compile those, and so far looks like it works, but only because we have gcc 3.2 as base compiler now. Hopefully libtool gets a bit smarter about this. --j Thread at a glance:
Previous Message by Date: click to view message previewRe: sfs on ia64 with gcc 3.2> From: Jaakko Niemi <liiwi@xxxxxxxxxxxxx> > Date: Sun, 23 Feb 2003 10:27:42 +0200 > > >> Mailing-List: contact sfs-help@xxxxxxxxxx; run by ezmlm > >> From: Jaakko Niemi <liiwi@xxxxxxxxxxxxx> > >> > >> On itree.h, around line 89, there is: > >> > >> #define eos ((int) &(((T *) 0)->*field).p) > >> > >> This does not work on 64-bit archs where int is 32-bit and > >> pointers 64-bit. Pointer gets cut and bad things happen. > >> > >> I'm not sure if there is better solution than casting that > >> to long instead of int. > > > > This should be fine. SFS compiles and runs fine on the alpha, which > > also has 64-bit pointers and 32-bit ints. Even though pointers are > > 64-bits, the size of data structure T is not going to be more than 2 > > Gigabytes (or else SFS wouldn't compile for 32-bit architectures). > > You mean it's ok to use long there? I'm afraid it's been so long that I've forgotten the context of this message. However, the code as written (with int) should be just fine. There must be some other problem. Maybe you could try: #define eos reinterpret_cast<int> (&(((T *) 0)->*field).p) What is the compiler error? > >> Problem here is that gcc does not grok c++ libs. So far, I haven't been > >> able > >> to come with cleaner solution than renaming funmount.c to funmount.cc. > >> > >> Weird thing is that this did not come up earlier. > >> > >> Comments? > > > > Strange. Are you saying this is only a problem for funmount, and not > > for anything else? > > funmount and agent/dirsearch are the problematic ones. Again, the details are fuzzy because I don't remember the email. dirsearch.c is a C program, which shouldn't even need C++ libraries. > > Have you tried compiling with static as well as shared libraries? > > This happens only with shared libs. So maybe libtool on the ia64 just doesn't support shared libraries yet. This would not be surprising, as getting C++ to work is a bit trickier, and in theory not supported until the next full version number of libtool (the so-called multi-lingual branch). David Next Message by Date: click to view message previewHelp in setting up sfs serverHello, I am using Redhat 7.2 (NPACI Rocks distro), and I have a problem in setting up SFS server. I have succeeded in building and running the client I followed your guide on Quick server setup. I have done the key generation successfully, create the sfsrwsd_config successfully. I also have changed the ownership of all the sfs files from the regular user to user 'root' and group 'sfs'. Yet, I still have a problem. The sfssd -d debug output shows 'findfs Permission denied' like this: [root@frontend-0 sbin]# ./sfssd -d sfssd: version 0.7.2, pid 4467 rexd: version 0.7.2, pid 4468 rexd: serving @frontend-0.tacc.utexas.edu,tx7ax73sy82ndq26zkytpjyuktsrf86p sfsauthd: version 0.7.2, pid 4469 rexd: spawning /tmp/CHORD/sfs-build/lib/sfs-0.7.2/ptyd sfsauthd: serving @frontend-0.tacc.utexas.edu,tx7ax73sy82ndq26zkytpjyuktsrf86p sfsrwsd: findfs: 127.0.0.1:/tmp/CHORD/root: NFS mount: Permission denied sfsrwsd: fatal: file server initialization failed sfssd: EOF from server This is my /etc/export : [root@frontend-0 sbin]# cat /etc/exports /usr/local/lsf 129.116.206.112/255.255.255.248(rw,no_root_squash) /export 129.116.206.112/255.255.255.248(rw) /export/home 129.116.206.112/255.255.255.248(rw) 129.116.206.92(rw) /tmp/CHORD/root localhost(rw) /tmp/CHORD/root/usr1 localhost(rw) And this is my sfsrwsd config: [root@frontend-0 sbin]# cat ../etcdir/sfsrwsd_config Export /tmp/CHORD/root / Export /tmp/CHORD/root/usr1 /usr1 The NFS export seems fine. Here is the result of showmount [root@frontend-0 sbin]# /usr/sbin/showmount -e Export list for frontend-0: /export 129.116.206.112/255.255.255.248 /usr/local/lsf 129.116.206.112/255.255.255.248 /export/home 129.116.206.112/255.255.255.248,129.116.206.92/tmp/CHORD/root frontend-0 /tmp/CHORD/root/usr1 frontend-0 The way I restarted NFS is by /sbin/service portmap stop /sbin/service nfs stop /sbin/service portmap start /sbin/service nfs start Your help is deeply appreciated... Thank you so much, Jeson Martajaya UTCS Austin Previous Message by Thread: click to view message previewRe: sfs on ia64 with gcc 3.2> From: Jaakko Niemi <liiwi@xxxxxxxxxxxxx> > Date: Sun, 23 Feb 2003 10:27:42 +0200 > > >> Mailing-List: contact sfs-help@xxxxxxxxxx; run by ezmlm > >> From: Jaakko Niemi <liiwi@xxxxxxxxxxxxx> > >> > >> On itree.h, around line 89, there is: > >> > >> #define eos ((int) &(((T *) 0)->*field).p) > >> > >> This does not work on 64-bit archs where int is 32-bit and > >> pointers 64-bit. Pointer gets cut and bad things happen. > >> > >> I'm not sure if there is better solution than casting that > >> to long instead of int. > > > > This should be fine. SFS compiles and runs fine on the alpha, which > > also has 64-bit pointers and 32-bit ints. Even though pointers are > > 64-bits, the size of data structure T is not going to be more than 2 > > Gigabytes (or else SFS wouldn't compile for 32-bit architectures). > > You mean it's ok to use long there? I'm afraid it's been so long that I've forgotten the context of this message. However, the code as written (with int) should be just fine. There must be some other problem. Maybe you could try: #define eos reinterpret_cast<int> (&(((T *) 0)->*field).p) What is the compiler error? > >> Problem here is that gcc does not grok c++ libs. So far, I haven't been > >> able > >> to come with cleaner solution than renaming funmount.c to funmount.cc. > >> > >> Weird thing is that this did not come up earlier. > >> > >> Comments? > > > > Strange. Are you saying this is only a problem for funmount, and not > > for anything else? > > funmount and agent/dirsearch are the problematic ones. Again, the details are fuzzy because I don't remember the email. dirsearch.c is a C program, which shouldn't even need C++ libraries. > > Have you tried compiling with static as well as shared libraries? > > This happens only with shared libs. So maybe libtool on the ia64 just doesn't support shared libraries yet. This would not be surprising, as getting C++ to work is a bit trickier, and in theory not supported until the next full version number of libtool (the so-called multi-lingual branch). David Next Message by Thread: click to view message previewFeel better, lose we1ght, and signs of aging. . fzyekr eul oh h*As seen on TV* The health discovery that reverses signs of aging naturally and that is completely safe and effective is on sale for a limited time! Buy a two-month supply of our product and we will give you one month free! All natural H_G_H Enhancer will help you with all of the following: - Reduce body fat and build muscle - Enrich your sex life - Help remove cellulite and wrinkles - Sleep better, improve vision and memory - Restore hair growth and color - Strengthen your immune system - Have more energy - Turn back time on your body's biological clock up to twenty years with just six months of use! *** IF YOU ARE NOT COMPLETELY SATISFIED WITH OUR PRODUCT WE WILL REFUND YOU YOUR MONEY, NO QUESTIONS ASKED *** Go here for more information: http://64.83.112.54/human/index.php?show=main&id=727 AOL USERS: <a href="http://64.83.112.54/human/index.php?show=main&id=727">Click here</a> fncfxbekjttlifdulg nhrwvgyftklbxp b heyae n mqrqd Loading Comments...
|
|
