Long filenames under DJGPP

[BoomSukka]

Quite simply, how do I get GCC to use them?

I hadn't noticed up until now because I didn't have any long filenames, but eventually I started having problems, and this is definitely the cause.

According to the FAQ on www.delorie.com/djgpp, I'm out of luck (the only info I could find was on LFN support for WinNT).

So, is this the case?

Thanks.
Tim.

[Anonymous]

http://www.delorie.com/djgpp/v2faq/faq22_16.html

[Tim]

Bah, don't bother. Use Cygwin. http://www.cygwin.com/

[BoomSukka]

I've read the FAQ entry supplied above, but I can't rectify the situation regardless of how I set LFN as an environment variable.

Cygwin? I may as well look into it...
ON SECOND THOUGHT... I think that's too far a departure from what I'm familiar with.

Is anyone using DJGPP under WinXP with long filenames?

Tim.

[Tim]

Oh, if you're using Windows XP, definitely use Cygwin.

It's not a departure from what you're used to at all -- it's the same gcc/binutils combo -- unless what you're used to is the Windows DPMI host crashing, a lack of long filenames, and NTVDM.EXE loading every time you run a DJGPP program.

My main problem with running DJGPP under Windows is that Windows is trying very hard to give DJGPP a real-mode DOS environment to run under; a virtual 8086 machine. However, DJGPP is trying just as hard to turn what it thinks is a real-mode DOS environment into a protected-mode environment. Using a native Windows environment to run gcc/binutils, like Cygwin, cuts out these extra layers. If you see no other benefits, you'll at least see it run faster.

[Pype.Clicker]

never tried cygwin myself, i'm still with DJGPP for MS-environment.

and my advice for long names is ... don't use them :p stick on 8.3 filenames... If you go to long file names, you may end in a situation where your file doesn't have the same name for the compiler and for the shell, which may break at many places.

Probably switching to cygwin is the wisest move.

[Solar]

8.3 filenames can be a real nuisance, as anyone can verify who ever had a look inside C:\Windows.

To be honest, I never understood why so many people are still using DJGPP at all. Is there a benefit to using it?

[Pype.Clicker]

probably no real benefit except that it's installed on my system for ages . Also, when i was still using my dos-based loader, it allowed me to rebuild the system and test it without entering/leaving windows ... now that i have a floppy bootloader, a development kit that allows both COFF and ELF formats and that i mastered BOCHS, it's no longer useful ... but it's still there ...

[Therx]

Surely we should all be writing makefiles and organising code so that it will compile on any GCC bug-free system. I must admit that I use long file names but I can get it to compile, unchanged, on both DJGPP and Cygwin. The only problem I foresee in the future is when my command line to ld gets too long with all the object files for the DOS command line.

Pete

[Perica]

..

[Therx]

I know but my makefile automatically compiles/assembles and then links all files it can find in the src/kernel folder. It would be a pain to have to change the makefile to add a new file. I want to have it so that ld reads the files from a text file which could be made on the fly.

Pete

[Slasher]

If you have too many files,do what i did. Build libray files with ar.Make sure you use the same format for the assembly and highlevel object code ie
nasm -fcoff *.asm -o *.o
and
(in the linker script for you c files)

output format("go-32-coff") //I think this is how its written but you get the ides

then
ar -rsd library_name1.lib asm_object_files.o c_object_files.o

ld ***** kernel_main.o library_name1.lib library_name2.lib
hope this helps

[Therx]

Unfortunately this still requires the makefile to have the object file names hardcoded. Does ar take file lists or wildcards for object files. If so maybe I could use that to link everything except the entry (with multiboot header) and then use ld to finalise.

Pete

[Candy]

What about using recursive makefiles? They were designed for this purpose, and with a bit of general programming you can make the makefile itself very clean indeed, with only a include in it for the ugly stuff

GNU method for subdirs (from linux makefiles):

SUBDIRS=kernel bootup libc etc

all:
$(MAKE) subdirs SDS="$(SUBDIRS)" TODO="all"

subdirs: $(patsubst %, _dir_%, $(SDS))

$(patsubst %, _dir_%, $(SDS)):
$(MAKE) -C $(patsubst _dir_%, %, $@) $(TODO)

and of course, use incremental linking (subdivide everything into logical packages, such as networking devices, disk devices, legacy devices, core, MM etc and link each into its own .o file. Then link all those .o files into one executable)

[Therx]

That's basically what my makefile does except its not split into subdirs. It automagically finds a compilable files and links them together. But as it still has to have the directory names hard coded I guess that each dir could be linked to a seperate library. the trouble is that currently I don't plan on having a complex dir structure just:-

kernel
include (obviously not compiled)
lib
drivers
apps

Do you think this will be enough subdivision to stop me reaching the terminal number of object files. I will probally further divide the drivers and apps folders in to seperate apps and types of device.

Pete

PS Attached my makefile for anyone who wants it. Linux users will have to change the install section which I havn't changed to use cp yet. Its got the extension c so that I can attach it.

[attachment deleted by admin]