On Fri, 20 Jun 2003, [iso-8859-1] 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 ?
You have set yourself a challenging task.
a) Compiling kernels of any sort can be done in any workstation
environment regardless of its libc environment. The version of the
compiler itself can be a factor, but isn't usually. This flexibility
applies to compiling modules as well, but there may be other concerns with
module compilation that depend on how the module was written. By far, the
safest way to compile modules is to compile them in the context of a
complete kernel/modules configuration and compilation.
b) Compiling applications generally _does_ require compiling against
glibc2.0 headers, and by far the easiest way to do this is in a slink
environment. However, slink used linux kernel 2.0.36, so the native
headers there don't support USB ioctl calls! This a significant problem,
because it is important to compile _applications_ using any version of
libc using the same kernel headers that the _libc_ library was compiled
with. (The actual kernel in use can be the same or newer... but the
applicaton needs to assume the kernel is no newer than the one glibc
assumes.)
It looks to me like you need a custom "cross-compiled" version of glibc2.0
that is compiled to use kernel 2.4.20 kernel headers, and you need to
compile your application against the same headers. This amounts to a
cross-compiling environment, so using slink is no longer buying you any
simplification. You would then need to use both your version of the glibc
.so file in your router, and then your application should work. Fair
warning: I have not done this myself... this is just based on my
understanding of the dependencies.
> > 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.
> But what's about segmentationn fault of binaries ?
That is a classic symptom of a binary compiled against a newer glibc
being executed on an older glibc system. There are other possible
explanations, but until you resolve your library problems I wouldn't
consider them.
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go...
Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...2k
---------------------------------------------------------------------------
-------------------------------------------------------
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
