[Scst-devel] Problem compiling scst 3.0 on 32 bit platform

[Pascal B. <pas...@fr...>]

Guys,

 

I have an SL(~RHEL) 6.5 32 bits-based node (older DELL 32 bits hardware),
kernel updated to 3.4.79 and regen'ed using a brand new installed GCC 4.8.2.

At installation time, some months ago, I installed SCST 2.2.1 without any
problem and it successfully served some ESXi nodes until now.

 

After checking SCST 3.0 benefits on other 64 bits platforms last few weeks,
I decided to update this server to 3.0 too. However, I'm facing problems at
compile time that I did not face on my 64 bits platforms (Same SL6.5, same
3.4.79 update).

 

Basically, scst_vdisk make fails with undefined symbols "__moddi3" and
"__umoddi3". Other handlers' make is ok.

 

I've RTFM'ed a bit, but in the 32 bits area the SCST README only talks about
that CONFIG_VMSPLI thing. I implemented it in case of, it effectively
suppressed a couple of warnings (At least I didn't missed everything.) but
it didn't fix my actual problem.

 

Digging the net, I found many issues talking about that problem, related to
64 bits operations issued in 32 bits environments and obviously requiring
libgcc that contains the missing entry points. But none of these articles
were in the SCST context.

 

To verify, I even recompiled my GCC following some articles suggestions, but
no luck, scst_vdisk still misses these symbols.

 

I also tried to recompile scst_vdisk module by hand, outside make using gcc,
but again no luck, obviously I'm not competent enough in GCC to achieve
that. I found some tricks on the net to workaround that, but they're mainly
focused on regular application software development, not kernel modules, and
obviously it's not the same stuff.

 

Well, now I'm stuck, don't know where to look then, is it my compiler config
that fails ? Or is it SCST ? After all, it compiled correctly in the very
same environment in 2.2.1. What could I use to compile scst_vdisk by hand
and force the reference to these symbols in libgcc ?

Any suggestion welcome.

 

Thanks!

 

Best regards,

 

Pascal.



---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com