i've found that the invocation of the shared-object creation line makes a difference.
the original invocation, pulling DynaLoader.a explicitly has getenv in a REL24 relocation: [EMAIL PROTECTED]:~/cockpit/build/linuxgcc/scripting$ g++ -fpic -shared -o libscripting-1-0.so PerlScriptingDef.o PerlWrapper.o ScriptingModuleDef.o -rdynamic /usr/lib/perl/5.6.0/auto/DynaLoader/DynaLoader.a && readelf -r libscripting-1-0.so | grep getenv 00016890 0840a R_PPC_REL24 00000000 getenv + 0 00038d9c 08415 R_PPC_JMP_SLOT 00000000 getenv + 0 without naming DynaLoader.a, getenv has no R_PPC_REL24 relocation entry. [EMAIL PROTECTED]:~/cockpit/build/linuxgcc/scripting$ g++ -fpic -shared -o libscripting-1-0.so PerlScriptingDef.o PerlWrapper.o ScriptingModuleDef.o -rdynamic && readelf -r libscripting-1-0.so | grep getenv 00036864 07915 R_PPC_JMP_SLOT 00000000 getenv + 0 is it legal to invoke a .a when creating a .so? it seems to make the difference in creating a valid .so > Actually, it shows me that your build scripts are not clean > enough to handle a decent architecture. =) maybe that's it thanks -- [EMAIL PROTECTED] Brad Midgley
