Thread: Problems with Orwell CPP

Does anyone from the Orwell community come here? I need hellp.

I have actually been trying to build the latest versions of a linker since I was finding problems using them last year. So the author has sent me a bunch of the builds. The first 3 build ok but crash when I go to use them. I am using Orwell CPP.

Orwell Dev-C++

I am using the first one that is 32bit for Windows on 32bit XP for home. .

The setup which includes MinGW32 4.8.1 can be downloaded here (63MB).

I thought either my Orwell build needed updating or something was wrong with my system. So I ran a memory check. 4 hours. No errors. Two hour cpu torture test. No errors. Ran system file check to make sure all critical files were ok. Ran Checkdisk. 4x. Uninstalled the old Orwell. Went in and yanked all leftovers bins.

Downloaded and installed the new Orwell which is only about a year newer than the last build that I had. It compiles the linker fine but crashes upon use. The author compiled a version on his system using Windows 2k and sent me the build. That build runs absolutely fine. The only thing that remains is there is something wrong with Orwell. Unless I'm overlooking something.

Code:

C:\Stuff\vlinkver\vlink12g>mkdir objects

C:\Stuff\vlinkver\vlink12g>mingw32-make

gcc -o objects/main.o -O2 -fomit-frame-pointer -c -DTYPES32BIT main.c

gcc -o objects/support.o -O2 -fomit-frame-pointer -c -DTYPES32BIT support.c

gcc -o objects/errors.o -O2 -fomit-frame-pointer -c -DTYPES32BIT errors.c

gcc -o objects/linker.o -O2 -fomit-frame-pointer -c -DTYPES32BIT linker.c

gcc -o objects/dir.o -O2 -fomit-frame-pointer -c -DTYPES32BIT dir.c

dir.c: In function 'close_dir':

dir.c:190:5: warning: passing argument 1 of 'free' discards 'const' qualifier fr

om pointer target type [enabled by default]

free(d);

^

In file included from vlink.h:16:0,

from dir.c:18:

c:\stuff\dev-cpp\mingw32\include\stdlib.h:238:38: note: expected 'void *' but ar

gument is of type 'const char *'

_CRTIMP void __cdecl __MINGW_NOTHROW free (void*);

^

gcc -o objects/targets.o -O2 -fomit-frame-pointer -c -DTYPES32BIT targets.c

gcc -o objects/ar.o -O2 -fomit-frame-pointer -c -DTYPES32BIT ar.c

gcc -o objects/ldscript.o -O2 -fomit-frame-pointer -c -DTYPES32BIT ldscript.c

gcc -o objects/pmatch.o -O2 -fomit-frame-pointer -c -DTYPES32BIT pmatch.c

gcc -o objects/expr.o -O2 -fomit-frame-pointer -c -DTYPES32BIT expr.c

gcc -o objects/t_amigahunk.o -O2 -fomit-frame-pointer -c -DTYPES32BIT t_amigahu

nk.c

gcc -o objects/t_elf32.o -O2 -fomit-frame-pointer -c -DTYPES32BIT t_elf32.c

gcc -o objects/t_elf32ppcbe.o -O2 -fomit-frame-pointer -c -DTYPES32BIT t_elf32p

pcbe.c

gcc -o objects/t_elf32m68k.o -O2 -fomit-frame-pointer -c -DTYPES32BIT t_elf32m6

8k.c

gcc -o objects/t_elf32i386.o -O2 -fomit-frame-pointer -c -DTYPES32BIT t_elf32i3

86.c

gcc -o objects/t_elf32arm.o -O2 -fomit-frame-pointer -c -DTYPES32BIT t_elf32arm

.c

gcc -o objects/t_elf64.o -O2 -fomit-frame-pointer -c -DTYPES32BIT t_elf64.c

gcc -o objects/t_aout.o -O2 -fomit-frame-pointer -c -DTYPES32BIT t_aout.c

gcc -o objects/t_aoutnull.o -O2 -fomit-frame-pointer -c -DTYPES32BIT t_aoutnull

.c

gcc -o objects/t_aoutm68k.o -O2 -fomit-frame-pointer -c -DTYPES32BIT t_aoutm68k

.c

gcc -o objects/t_aouti386.o -O2 -fomit-frame-pointer -c -DTYPES32BIT t_aouti386

.c

gcc -o objects/t_aoutmint.o -O2 -fomit-frame-pointer -c -DTYPES32BIT t_aoutmint

.c

gcc -o objects/t_ataritos.o -O2 -fomit-frame-pointer -c -DTYPES32BIT t_ataritos

.c

gcc -o objects/t_rawbin.o -O2 -fomit-frame-pointer -c -DTYPES32BIT t_rawbin.c

gcc -o objects/t_vobj.o -O2 -fomit-frame-pointer -c -DTYPES32BIT t_vobj.c

gcc -o objects/version.o -O2 -fomit-frame-pointer -c -DTYPES32BIT version.c

gcc -o vlink objects/main.o objects/support.o objects/errors.o objects/linker.

o objects/dir.o objects/targets.o objects/ar.o objects/ldscript.o objects/pmatch

.o objects/expr.o objects/t_amigahunk.o objects/t_elf32.o objects/t_elf32ppcbe.o

objects/t_elf32m68k.o objects/t_elf32i386.o objects/t_elf32arm.o objects/t_elf6

4.o objects/t_aout.o objects/t_aoutnull.o objects/t_aoutm68k.o objects/t_aouti38

6.o objects/t_aoutmint.o objects/t_ataritos.o objects/t_rawbin.o objects/t_vobj.

o objects/version.o



C:\Stuff\vlinkver\vlink12g>

Here it is when it runs.

Code:

C:\jaguar\wrkhello>make



Microsoft (R) Program Maintenance Utility Version 1.50

Copyright (c) Microsoft Corp 1988-94. All rights reserved.



smac -fb startup.s

startup.s[82]: Warning: GPU/DSP code outside of absolute section

vc -DJAGUAR -O2 -c -o jag.o jag.c

warning 208 in function "__main": suspicious loop

vlink12g -t -EB -brawbin1 -Ttext 0x4000 startup.o jag.o -L/jaguar/lib -

lvbcc -o jag.bin



Loading files:



startup.o (aoutnull object)

jag.o (aoutnull object)

/jaguar/lib\libvbcc.a (aoutnull library)



Digesting symbol information:



Joining selected sections:



Copying .text:

Copying .data:

Copying .bss:

NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0xc00000

05'

Stop.



C:\jaguar\wrkhello>

It always crashes at exactly the same place.

The author tried this and sent me the build. He normally only uses Linux.

I found a Windows 2000 system with MS Visual Studio C++/.NET 7.0 at work,
in the office. I compiled the recent vlink source with:

nmake -f Makefile.Win32

No problems (no warnings, no errors) while compiling. Executable is fine.
I attached it for you.

Testing it with your Jaguar object files showed no problem either (see
screenshot "vlink.jpg"). I added the -t option to trace what the linker
is doing.


> What do you suggest I do now?

When the attached vlink executable works for you, then there is something
wrong in your build-process.

Which compiler did you use? And how did you compile vlink?


Regards,

The build that he sent me runs fine. No crashes.


Does this problem sound familiar to anyone else? I tried using MS Visual Studio but after a while it ate all my setpaths on my system. It was a monsterous hassle to undo.
If anyone wants I can send the object files to link and the linker source to compile if they also use Orwell and want to try it.

Any help or insight anyone can give me with this would be greatly appreciated.

I may have made a mistake. Can a mod please remove all copies of names and emails from this post? I am very sorry.

Mod: Done, though I don't really see the point - googling for the code will probably reveal the origin site.

This doesn't look like a Dev-C++ problem to me. It's telling you that you shouldn't free memory pointed to by a const pointer. When you do, you risk crashing the program by trying to free memory that was not allocated on the heap. This is a problem with your code, not the program used to build it.

It's telling you that you shouldn't free memory pointed to by a const pointer. When you do, you risk crashing the program by trying to free memory that was not allocated on the heap.

O_o

The `const' modifier is decoration for the compiler and programmer; you can't determine where a "pointee" lives by just seeing `const' on the pointer.

*shrug*

Anyway, the list makes it look as if it isn't "vlink" that returns a non-zero aborting the build.

Soma

Originally Posted by phantomotap

O_o

The `const' modifier is decoration for the compiler and programmer; you can't determine where a "pointee" lives by just seeing `const' on the pointer.

True, but I think the warning is intended to prevent things like freeing a pointer to a string literal, for example.

True, but I think the warning is intended to prevent things like freeing a pointer to a string literal, for example.

O_o

True enough; I'm more enforcing, attempting at least, the idea of looking where memory actually comes from rather than any given declaration.

Soma