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

What exactly do you mean by 1024 boundry ?

Haven't looked at the code specifically for this, but I'd be *mighty* surprised if a re-compile of code that old fixed it.

Generally the issue is the BIOS support of the INT13 extensions. I can't see a simple recompile fixing any coding shortcomings.

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

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.
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.

exvor, the OP is running code from a 2.2.12 timeframe.
Comparing current code levels is unlikely to be relevant.

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

oops


Why not use a newer code base of cfdisk and then look at the old one and see how they fixed it.