Problems with Orwell CPP

This is a discussion on Problems with Orwell CPP within the Windows Programming forums, part of the Platform Specific Boards category; Does anyone from the Orwell community come here? I need hellp. I have actually been trying to build the latest ...

  1. #1
    Registered User
    Join Date
    Sep 2006
    Location
    Beaverton, Oregon, United States
    Posts
    163

    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.
    Last edited by CornedBee; 4 Weeks Ago at 04:31 PM. Reason: Removed names as per request.

  2. #2
    Registered User
    Join Date
    Sep 2006
    Location
    Beaverton, Oregon, United States
    Posts
    163
    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.
    Last edited by CornedBee; 4 Weeks Ago at 04:32 PM.

  3. #3
    Registered User
    Join Date
    Oct 2006
    Posts
    2,406
    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.
    Code:
    namespace life
    {
        const bool change = true;
    }

  4. #4
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,257
    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
    “Often out of periods of losing come the greatest strivings toward a new winning streak.” -- Fred Rogers
    “Salem Was Wrong!” -- Pedant Necromancer

  5. #5
    Registered User
    Join Date
    Oct 2006
    Posts
    2,406
    Quote Originally Posted by phantomotap View Post
    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.
    Code:
    namespace life
    {
        const bool change = true;
    }

  6. #6
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,257
    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
    “Often out of periods of losing come the greatest strivings toward a new winning streak.” -- Fred Rogers
    “Salem Was Wrong!” -- Pedant Necromancer

  7. #7
    Registered User
    Join Date
    Sep 2006
    Location
    Beaverton, Oregon, United States
    Posts
    163
    It does seem to be a code error because I compiled the latest version of this fine with no warnings. And runs without crashing.

  8. #8
    Registered User
    Join Date
    Sep 2006
    Location
    Beaverton, Oregon, United States
    Posts
    163
    Just to wrap this up while talking with the author he theorizes

    The big difference is that since V0.13 the source uses C99 stdint.h, so it
    doesn't depend anymore on TYPES32BITS/TYPES64BITS. So my guess is that
    TYPES32BITS was wrong for your compiler, when compiling 0.12...

  9. #9
    Registered User
    Join Date
    Sep 2006
    Location
    Beaverton, Oregon, United States
    Posts
    163
    And thanks to everyone for their time and input! Much appreciated.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Arduino Simulator using orwell dev cpp
    By Paulware in forum Projects and Job Recruitment
    Replies: 0
    Last Post: 05-15-2013, 09:48 PM
  2. fread problems or memory problems
    By Lechuza in forum C Programming
    Replies: 1
    Last Post: 03-22-2009, 12:45 PM
  3. Linking problems, class problems
    By Kheila in forum C++ Programming
    Replies: 12
    Last Post: 11-22-2005, 12:47 AM
  4. Problems
    By dylanburford in forum C++ Programming
    Replies: 3
    Last Post: 11-06-2005, 10:22 AM
  5. Still having problems...
    By Gamma in forum C++ Programming
    Replies: 4
    Last Post: 04-14-2002, 06:45 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21