ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I was wondering if it is possible to recompile cfdisk
2.11 with gcc 2.7.2 to work around the 1024 boundery limitation without haveing to recompile a libc. I have debian slink 2.2.12 kernel. I also have an older version of cfdisk source mabe that would be a better place to startI am not sure? I use cfdisk to set the boot flags on my bootable partitions from linux it is quite handy. If anything could some one give me a few hints as to ware to start looking in the source code to solve the problem
thanks in advance
Hmmm I find that rather interesting! this is what acually happens, everything works fine as long as I keep all my partitions inside the 1024 boundry or rather the 8 gig limit.I partition with partition magic 8.0 so the moment I create a partition past that particular mark cfdisk complains of a
bad primary partition 0: partition ends after end of disk
and shuts down.
So I guess what you are saying to me is that there is no way to rewrite the code without haveing to compile a new libc. I just dont buy that, there has to be a way. what do I look for in traceing the program?? It seems to me that what ever the programing is looking for to generate the error just needs to be taken out and it should work
BTW where could one find a complete package for updateing libc gcc and the like or is there not one? I really dont like all the blote of the newer distros and the hardware incompatibilities what i have works for me and I think with a little tweeking could be fixed just need a little help
I'm not familiar with cfdisk, but I have to ask: where did recompiling libc come in?
As I understand it, syg00 referred to BIOS and INT13 handling. To me, that's "external hardware." Recompiling libc won't make a lick of difference it the problem lies in a hardware design limitation. To give an example of what I mean, if the internal bus of a processor only has 32 address lines, then the processor can only address 4GiB of memory... period. No recompiling of software (application, library, or even kernel) will ever allow the processor to address more than 4Gib; it's a physical limitation of the hardware.
I have a feeling this 1024 limit (though again, not familiar with it) is based on a similar type of hardware design standard. Just my
So I guess what you are saying to me is that there is no way to rewrite the code without haveing to compile a new libc.
No I wasn't saying anything of the sort. Now that I know you can allocate beyond 1024, that means the BIOS supports it, and the problem is most likely with cfdisk - as you surmised.
Fixing the code may be as simple as getting a later version of cfdsik - might compile with your tool-chain with a bit of luck.
Else it should give you an idea of the changes required - probably just a check added (note) to see if the extensions are supported, and use them in future calls.
Quote:
BTW where could one find a complete package for updateing libc gcc and the like or is there not one? I really dont like all the blote of the newer distros and the hardware incompatibilities what i have works for me and I think with a little tweeking could be fixed just need a little help
Can't help there - I don't (personally) reckon dicking around with the tool chain is worth all the grief. I'd upgrade - bloat is in the eye of the beholder. Surely you could build a Debian system with just what you want (if you want to stay with Debian - other "light" options available).
I use cfdisk all the time and have no issues being able to parttion drives larger then 8g. Example is the computer im working on now with a 100g drive used cfdisk to create the 20 and 30g parttions.
Partition limits are bios issues and sometimes can be partion software issues but im pretty sure cfdisk does not suffer from such issue.
No I wasn't saying anything of the sort. Now that I know you can allocate beyond 1024, that means the BIOS supports it, and the problem is most likely with cfdisk - as you surmised.
Fixing the code may be as simple as getting a later version of cfdsik - might compile with your tool-chain with a bit of luck.
yeah I have tried compileing cfdisk 2.11 and thats where the new libc comes in seeing as all I have is a 200 mghz cpu and 64 megs ram compileing a new libc will take quite a chunk of time I was hopeing there might be a solution around that.
btw I did find a version cfdisk 0.8g that does run but it does not read my partitions corrrectly mostly the free space at the end of the drive if anyone knows anything about that version and getting its sourcecode would be appeciated thanks
the only thing i really use cfdisk for is checking quikly to see what my partitions are as linux sees them becouse i manually mount any partitions that I need at the time its pretty handy for that
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.