Need a little help with compile time options

I have these makefile macros:

Code:

---

build_apple=-D _MAC
build_win16=-D _WIN16
build_win32=-D _WIN32 -mabi=ms -march=i386
build_win64=-D _WIN64 -mabi=ms -march=x86-64

---

When make gets to launching the win32 compile gcc spits this at me:

Quote:

---

cc1: error: CPU you selected does not support x86-64 instruction set

---

I'm assuming I gave the option the wrong value but there was none that was called x86 and from my memory i386 is what that usually refers to. Would appreciate some help here, btw compiling on linux so msc is not an option... not that I would use it if I could help it.

I'm in Linux Mint (derivative of Ubuntu) and I installed the gcc-mingw-w64-i686 package. Then I was able to compile with "i686-w64-mingw32-gcc -D _WIN32 -mabi=ms -march=i386", plus the source file names. So you might need to check which compiler you're using to ensure it supports 32-bit x86.

Quote:

---

Originally Posted by christop

I'm in Linux Mint (derivative of Ubuntu) and I installed the gcc-mingw-w64-i686 package. Then I was able to compile with "i686-w64-mingw32-gcc -D _WIN32 -mabi=ms -march=i386", plus the source file names. So you might need to check which compiler you're using to ensure it supports 32-bit x86.

---

I appreciate the response however the binary being executed matters little when compiling for another cpu, what matters is what the compiler version in general supports since what it's doing is translating c/c++ to asm which is then passed onto an asm compiler. In this case the compiler seems to think x86_64 should be used despite me explicitly saying otherwise during the object compile:

Code:

---

cc -fPIC -D _WIN32 -mabi=ms -march=i386 -D build_shared_libpaw_min -Wall -Wextra  -I ".../include" -o ".../.paw/_/objs/libpaw-min/buffer.c.shared32.o" -c ".../src/libpaw-min/buffer.c"

---

You might need an linker option or a different compiler/toolchain both are just guesses.

Quote:

---

Originally Posted by stahta01

You might need an linker option or a different compiler/toolchain both are just guesses.

---

If the error occurred during link time I could understand the suggestion of a different linker, curios to know who you arrived at that result, as for the different compiler/toolchain, I did install mingw before this but every variation of "mingw-gcc" I could think of didn't work out, the only information of what the binary was called I could find was just "use gcc", that was not helpful to me, if you happen to know what to use to explicitly indicate the mingw compiler I would be happy to read it.

Edit: btw admin, if you think of a better title for this thread that more accurately summarises the problem, feel free to change the title as I couldn't think of one

Found the cause, turned out I was using the wrong option, shoulda been using -m32 and -m64 instead of the respective -march options, finally got compile time issues which I can only put down to my usage of -D _WIN32 and -D _WIN64, not sure what to use instead though or whether I'm supposed to define anything there at all, I'll try without.

Edit: Nope, that made it worse, they needed to be defined. Since they're all, if not mostly, related to mingw I'll post the error here 1st to see if anyone familiar with mingw knows what else I need to add to my options to silence this:

Code:

---

/usr/i686-w64-mingw32/include/_mingw.h:586:14: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__debugbreak’

---

And the bit of code in that region (1st instance of __debugbreak is the line that triggers the above):

Code:

---

#ifdef __MINGW_INTRIN_INLINE
#ifdef __has_builtin
#define __MINGW_DEBUGBREAK_IMPL !__has_builtin(__debugbreak)
#else
#define __MINGW_DEBUGBREAK_IMPL 1
#endif
#if __MINGW_DEBUGBREAK_IMPL == 1
void __cdecl __debugbreak(void);
__MINGW_INTRIN_INLINE void __cdecl __debugbreak(void)
{
#if defined(__i386__) || defined(__x86_64__)
  __asm__ __volatile__("int {$}3":);
#elif defined(__arm__)
  __asm__ __volatile__("udf #0xfe");
#elif defined(__aarch64__)
  __asm__ __volatile__("brk #0xf000");
#else
  __asm__ __volatile__("unimplemented");
#endif
}
#endif
#endif

---

And just in case, the warning options I used:

Code:

---

WALL?=-Wall -Wextra -pedantic -Werror -Wfatal-errors

---

Due to the lack of replies I'm assuming either no one had any ideas, were asleep, or just decided the thread had started to deviate from the original problem too much so I started a thread here:
MinGW-w64 - for 32 and 64 bit Windows / Discussion /
Open Discussion: Compile time issues on linux

I'll still pay attention to this thread just in case

Quote:

---

Originally Posted by christop

I'm in Linux Mint (derivative of Ubuntu) and I installed the gcc-mingw-w64-i686 package. Then I was able to compile with "i686-w64-mingw32-gcc -D _WIN32 -mabi=ms -march=i386", plus the source file names. So you might need to check which compiler you're using to ensure it supports 32-bit x86.

---

I stand, er, sit corrected, the binary apparantly DID matter, at least as far as the silencing the mingw header warnings/errors go, while hunting the net for info I came across this:

MinGW-w64 - for 32 and 64 bit Windows / Wiki2 / UsingLinuxBinaries

which did use the prefix so I decided to just try it since I had no other leads and it worked well enough that I didn't even need to declare the mingw directories so now I'm just dealing with non-errors that are flagging up most likely because of the -pedantic option, the 1st was that I assumed like size_t vs SIZE_T microsoft had opted to use PTRDIFF_T instead of ptrdiff_t, they didn't so I got a more simple typedef now, as for the rest, was casting down directly from uintmax_t to void* and the compiler didn't like that, so now I'm putting uintptr_t between the casts and the original variables