[OpenAFS] sysname=ppc_linux26: Problems compiling

[Jeffrey Hutzelman]

--==========2317139384==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Sunday, November 21, 2004 23:24:43 +0100 Sergio Gelato 
<Sergio.Gelato@astro.su.se> wrote:

>> Cannot determine sys_call_table status. assuming it isn't exported
>
> A quick look in /usr/src/linux gave me the impression (I'll double-check)
> that gentoo-dev-sources does export this. Shows up as "D" in my
> System.map.

Irrelevant.  On 2.4, the method we use to detect whether a symbol is 
exported depends on CONFIG_MODVERISONS; otherwise it doesn't work.  On 2.6, 
it doesn't work ever.  In either case, if we can't tell if the symbol is 
exported at configure time, we have to (for now) assume it is not.

Note that this is mostly not a problem, as we now support an alternate 
user/kernel interface that does not require using our traditional syscall. 
However, for the moment you won't get PAG support if we can't find the 
sys_call_table.


> On x86 there is the additional, closely related problem that aclocal.m4
> has explicit code to make the config_modversions test fail on Linux 2.6.
> As a result, the build system sets MPS="SP MP", which may be right for
> Red Hat but breaks on Gentoo.

The problem here is that we're using CONFIG_MODVERSIONS for two things:
- To tell whether it is possible to tell if symbols are exported
  (the test works only if CONFIG_MODVERSIONS is set).  On Linux 2.6,
  the test never works, so we pretend CONFIG_MODVERSIONS is not set.

- To tell whether it is safe/useful to build SP and MP modules from the
  same set of headers by setting different preprocessor macros
  (this works only if CONFIG_MODVERSIONS is not set).  This actually
  has nothing to do with distributions -- it was safe and convenient
  in Linux 2.2 and 2.4.  In Linux 2.6, it doesn't matter anyway because
  we use the kernel's build system, and you only get one module that way.

I agree that in a Linux 2.6 world, you don't want to set MPS="SP MP" based 
on CONFIG_MODVERSIONS; instead you always want to set it correctly based on 
the kernel you're building for.

> Short-term, I'd go for patching the configure script in whatever way is
> appropriate for Gentoo. But maybe upstream should decouple the setting
> of MPS from the sys_call_table guesswork (and improve the heuristic for
> the latter, though that's perhaps more easily said than done).

You want mps_linux26-new.diff from ticket #15645.
Unfortunately, I was dumb and added that patch in a form that makes it not 
visible to the general public.  I've attached a copy to this message.


As far as doing sys_call_table detection better...
There is little we can do at configure time to detect what symbols are 
exported by the kernel.  In 2.4, we could check for the presence of the 
preprocessor macros which define the symbol versions for exported symbols, 
but only of CONFIG_MODVERSIONS was set.  Because of changes in 2.6 in the 
build system and in how symbol versioning works, that is no longer 
possible.  Lacking that, we have to take a conservative approach and assume 
the symbol is not exported.  It's not really much of a heuristic.

On the positive side, the in-kernel module loader in 2.6 handles weak 
symbol references.  So, I'm working on a mechanism that will allow us to do 
the best we can at finding the syscall table based on what symbols are 
exported _at run time_.


>> compile_et.o(.text+0xcb2): In function `yyerror':
>> :undefined reference to `yylineno'
>
> Haven't seen that one, sorry.

IIRC this is known lossage resulting from a change in flex.  I don't recall 
what the workaround is, but I'm sure there are people reading who do.


-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

--==========2317139384==========
Content-Type: application/octet-stream; name="mps_linux26-new.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="mps_linux26-new.diff"; size=2533

SW5kZXg6IGFjaW5jbHVkZS5tNAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvY3ZzL29wZW5hZnMvYWNp
bmNsdWRlLm00LHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjExNwpkaWZmIC11IC1yMS4xMTcgYWNp
bmNsdWRlLm00Ci0tLSBhY2luY2x1ZGUubTQJMjUgQXVnIDIwMDQgMjA6Mzk6MjEgLTAwMDAJMS4x
MTcKKysrIGFjaW5jbHVkZS5tNAkxOCBPY3QgMjAwNCAwMTowMDowMSAtMDAwMApAQCAtMTU3LDYg
KzE1NywxMCBAQAogCQlmaQogCQlBQ19NU0dfUkVTVUxUKGxpbnV4KQogCQlpZiB0ZXN0ICJ4JGVu
YWJsZV9rZXJuZWxfbW9kdWxlIiA9ICJ4eWVzIjsgdGhlbgorCQkgQUZTX1NZU0tWRVJTPWBlY2hv
ICRMSU5VWF9WRVJTSU9OIHwgYXdrIC1GXC4gJ3twcmludCAkW10xICRbXTJ9J2AKKwkJIGlmIHRl
c3QgIngke0FGU19TWVNLVkVSU30iID0gIngiOyB0aGVuCisJCSAgICAgICAgQUNfTVNHX0VSUk9S
KENvdWxkbid0IGd1ZXNzIHlvdXIgTGludXggdmVyc2lvbiBbMl0pCisJCSBmaQogCQkgaWYgdGVz
dCAieCRlbmFibGVfZGVidWdfa2VybmVsIiA9ICJ4bm8iOyB0aGVuCiAJCQlMSU5VWF9HQ0NfS09Q
VFM9IiRMSU5VWF9HQ0NfS09QVFMgLWZvbWl0LWZyYW1lLXBvaW50ZXIiCiAJCSBmaQpAQCAtMTk0
LDcgKzE5OCw3IEBACiAJCSBMSU5VWF9TQ0hFRF9TVFJVQ1RfVEFTS19TVFJVQ1RfSEFTX1NJR0hB
TkQKIAkJIExJTlVYX1NDSEVEX1NUUlVDVF9UQVNLX1NUUlVDVF9IQVNfU0lHTUFTS19MT0NLCiAJ
CSBMSU5VWF9XSElDSF9NT0RVTEVTCi0gICAgICAgICAgICAgICAgIGlmIHRlc3QgIngkYWNfY3Zf
bGludXhfY29uZmlnX21vZHZlcnNpb25zIiA9ICJ4bm8iOyB0aGVuCisgICAgICAgICAgICAgICAg
IGlmIHRlc3QgIngkYWNfY3ZfbGludXhfY29uZmlnX21vZHZlcnNpb25zIiA9ICJ4bm8iIC1vICRB
RlNfU1lTS1ZFUlMgLWdlIDI2OyB0aGVuCiAgICAgICAgICAgICAgICAgICAgQUNfTVNHX1dBUk4o
W0Nhbm5vdCBkZXRlcm1pbmUgc3lzX2NhbGxfdGFibGUgc3RhdHVzLiBhc3N1bWluZyBpdCBpc24n
dCBleHBvcnRlZF0pCiAgICAgICAgICAgICAgICAgICAgYWNfY3ZfbGludXhfZXhwb3J0c19zeXNf
Y2FsbF90YWJsZT1ubwogCQkgICBpZiB0ZXN0IC1mICIkTElOVVhfS0VSTkVMX1BBVEgvaW5jbHVk
ZS9hc20vaWEzMl91bmlzdGQuaCI7IHRoZW4KQEAgLTY0Myw3ICs2NDcsNiBAQAogCWVzYWMKIAlj
YXNlICRBRlNfU1lTTkFNRSBpbgogCQkqX2xpbnV4KikKLQkJCUFGU19TWVNLVkVSUz1gZWNobyAk
TElOVVhfVkVSU0lPTiB8IGF3ayAtRlwuICd7cHJpbnQgJFtdMSAkW10yfSdgCiAJCQlpZiB0ZXN0
ICJ4JHtBRlNfU1lTS1ZFUlN9IiA9ICJ4IjsgdGhlbgogCQkJIEFDX01TR19FUlJPUihDb3VsZG4n
dCBndWVzcyB5b3VyIExpbnV4IHZlcnNpb24uIFBsZWFzZSB1c2UgdGhlIC0td2l0aC1hZnMtc3lz
bmFtZSBvcHRpb24gdG8gY29uZmlndXJlIGFuIEFGUyBzeXNuYW1lLikKIAkJCWZpCkluZGV4OiBz
cmMvY2YvbGludXgtdGVzdDMubTQKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2cy9vcGVuYWZzL3Ny
Yy9jZi9saW51eC10ZXN0My5tNCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMApkaWZmIC11IC1y
MS4xMCBsaW51eC10ZXN0My5tNAotLS0gc3JjL2NmL2xpbnV4LXRlc3QzLm00CTI2IEF1ZyAyMDA0
IDE4OjE0OjM3IC0wMDAwCTEuMTAKKysrIHNyYy9jZi9saW51eC10ZXN0My5tNAkxOCBPY3QgMjAw
NCAwMTowMDowMSAtMDAwMApAQCAtNDUsNyArNDUsNyBAQAogWyNpbmNsdWRlIDxsaW51eC92ZXJz
aW9uLmg+CiAjaW5jbHVkZSA8bGludXgvY29uZmlnLmg+CiBdLAotWyNpZiAhZGVmaW5lZChDT05G
SUdfTU9EVkVSU0lPTlMpIHx8IChMSU5VWF9WRVJTSU9OX0NPREUgPj0gS0VSTkVMX1ZFUlNJT04o
Miw2LDApKQorWyNpZiAhZGVmaW5lZChDT05GSUdfTU9EVkVSU0lPTlMpCiBsb3NlOwogI2VuZGlm
CiBdLApAQCAtNTMsNyArNTMsOSBAQAogICBhY19jdl9saW51eF9jb25maWdfbW9kdmVyc2lvbnM9
bm8pXSkKICAgQUNfTVNHX1JFU1VMVCgkYWNfY3ZfbGludXhfY29uZmlnX21vZHZlcnNpb25zKQog
ICBBQ19NU0dfQ0hFQ0tJTkcod2hpY2gga2VybmVsIG1vZHVsZXMgdG8gYnVpbGQpCi0gIGlmIHRl
c3QgIngkYWNfbGludXhfcmhjb25maWciID0gInh5ZXMiIC1vICJ4JGFjX2N2X2xpbnV4X2NvbmZp
Z19tb2R2ZXJzaW9ucyIgPSAieG5vIjsgdGhlbgorICBpZiB0ZXN0ICJ4JGFjX2xpbnV4X3JoY29u
ZmlnIiA9ICJ4eWVzIjsgdGhlbgorICAgICAgTVBTPSJNUCBTUCIKKyAgZWxpZiB0ZXN0ICJ4JGFj
X2N2X2xpbnV4X2NvbmZpZ19tb2R2ZXJzaW9ucyIgPSAieG5vIiAtYSAiJEFGU19TWVNLVkVSUyIg
LWx0IDI2OyB0aGVuCiAgICAgICBNUFM9Ik1QIFNQIgogICBlbHNlCiAgIEFDX0NBQ0hFX1ZBTChh
Y19jdl9saW51eF9jb25maWdfc21wLCBbCg==

--==========2317139384==========--