At 07:45 PM 6/20/2003 +0200, Bibinsa wrote:
--- Ray Olszewski <[EMAIL PROTECTED]> a �crit : > At 05:26 PM 6/20/2003 +0200, Bibinsa wrote: > A plausible guess. gcc has changed a lot since Slink > (especially in the > last 6 months). Since the kernel is compiled > statically, it does not need > to "match" the compilation environment of the rest > of the distro, so you > need not turn to Slink.
So I shouldn't use the Debian/slink UML to compile the package ?
Maybe yes, maybe no. But realistically, if the module source is using features that are only supported by newer versions of gcc, noboby is going to take the time to fix that. So before I spent any time trying to untangle Slink-related messiness, I would certainly first try a distro with a newer gcc and related stuff.
As to the specifics of the Slink problem ... well, all you said about it was: "parse error in the kernel-source (debian 2.4.20). I think of a gcc trouble but I'm not sure..." Do you really expect to get specific advice about such a vague description of a problem with a non-standard driver?
> Without details of the failure ("unresolved symbol" > usually goes with an > insmod failure to load a module, not a "crash", so > I'm really uncertain > about what you are describing here), it is hard to > offer specific help. One > common source of "unresolved symbol" errors is > failure to insmod another > required module before the one you are currently > insmod'ing (this is a > mistake even quite knowledgeable people make these > days, because they are > used to using modprobe, which checks for and handles > dependency issues). > > Since we are talking about USB, you might have > compiled some other USB > stuff as modules and need to load that first. That's > about as far as I can > go without a better trouble report.
I'm gonna check dependencies with usb modules right now.
One moe thing: When I read your first message I read it to mean that you were recompiling the entire kernel (based on the Slink problem you identified). In re-reading it, I now realize that I may have misinterpreted what you said. If you are *just* compiling this module, you will need to match it to whatever kernel you wish to apply it to. I expect Jacques' docs have information about how to do that for his Bering kernels, so you might want to verify that you followed his suggested procedure.
But what's about segmentationn fault of binaries ?
What about it? Again, you didn't give us much to go on, only "and tools (adictrl, ...) craches too (segmentation fault)".
I assume the "..." part means you aren't even supplying the *names* of all the binaries you are having trouble with, let alone the details of how you call them, what userid is involved, whether they are compiled against the right shared libraries (this does matter for binaries, though not for the kernel itself), and anything else that might be helpful.
I suppose they **might** be failing merely because they expect to find a working kernel module, but it did not install successfully, so the app has problems operating ... but I really do not know. Segfaulting in that case would be pretty ugly, but not unheard of.
You should also consider reporting these problems to the mailing list, whatever it is, that supports the package you are trying to compile.
------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
