x86dbg build on macos/linux 10.12.1 fails stdio.h inclusion .. about os HOT 18 CLOSED

@evangreen i'm running into the same issue as @seclorum uncommenting line 517 gives me:

gcc-6 -I /Users/johan/Projecten/raspberrypi/os/apps/ck/lib/build/.. -I /Users/johan/Projecten/raspberrypi/os/include -DNDEBUG=1 -c -o ckcore.o /Users/johan/Projecten/raspberrypi/os/apps/ck/lib/build/../ckcore.S

from os.

I wasn't able to reproduce the assembler issue @seclorum and @aequitas are experiencing. Maybe I'm using a slightly older version of xcode+macOS. But I have a theory that the build assembler needs the -Wa,-I$(SRCDIR) flag passed to it to find the right file. If either of you have a second, can you pull down the latest change and give it a try? If that doesn't fix things I'll upgrade tonight to get a repro.

I'm still working on the right fix for the --sysroot part. That one I can reproduce. Turns out my relocatable GCC is not so relocatable.

from os.

same issue here - looks like when BINARYTYPE = library - it uses i686-pc-minoca-gcc but when BINARYTYPE = build then system gcc is used ...

I'm using prebuild tool stack - will try to build one from scratch ...

from os.

quickfix is modify in minoca.mk:136: CC := i686-pc-minoca-gcc --sysroot=$(TOOLROOT)

from os.

Quickfix worked - thanks s-u-p-e-r-t-r-a-m-p ..

from os.

Okay, new issue, possibly similar/related:

ake[5]: Nothing to be done for `all'.
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/apps/ck/lib/gram
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/apps/ck/lib/build
Assembling - ckcore.S
/Users/seclorum/Documents/minocaOS/src/os/apps/ck/lib/build/../ckcore.S:55:70: error: Could not find incbin file 'ckcore.ck'
.global __binary_ckcore_ck_start; __binary_ckcore_ck_start:; .incbin "ckcore.ck"; .global __binary_ckcore_ck_end; __binary_ckcore_ck_end:

 seclorum@github:~/Documents/minocaOS/src/os {(master)}
$ find . -name ckcore.ck
./apps/ck/lib/ckcore.ck

EDIT: I added a new issue: #26
(Not related, just similar in that its a macos toolchain issue)

from os.

Thanks for bearing with us guys. The macOS build support is very new, so the build system clearly has some bugs to work through. Chris is going to try to replicate this issue on his laptop. My suspicion for the first issue is it's in the way we build GCC off in https://gitlab.com/minoca/third-party/blob/master/build/gcc-4.9.2/build.sh when we created the prebuilt tools. I suspect the sysroot parameter needs to be different to activate GCC's "let me figure out automagically where I am".

The second issue seclorum posted looks like a build assembler path issue. We use the incbin assembler directive to include files directly into a binary, and the assembler seems to not be finding the file from the source directory.

@seclorum can you remove the @ from line 517 of minoca.mk so that we can see the full assembler line? Also, can you post the result of as --version?

from os.

Okay, I've pushed a change to the third-party repository to address the --sysroot change. When configuring GCC, --sysroot must be a subdirectory of --prefix for the relocatable stuff to kick in. The change in third party sets both of those to be equal to each other (but not "/", which alone seems to be insufficient).

I've uploaded a new set of MacOS and Windows tools to the website. These should hopefully be relocatable. I'll do the Linux tools tomorrow morning. Please give the new tools for Mac a try (remembering to revert supertramp's quick fix above).

ps- Thanks @s-u-p-e-r-t-r-a-m-p for the quick fix, it was helpful not only in getting people unblocked (or at least onto the next issue) but in diagnosing the problem.

from os.

With the toolchain as of today (November 2), per your instructions I re-built things, without s-u-p-e-r-t-r-a-m-p's fix (backed out) .. and thus, I get past the problem I reported at the top of this issue - missing stdio.h - but I still have the .incbin problem ..

Compiling - cdump.c
Assembling - ckcore.S
/Users/seclorum/Documents/minocaOS/src/os/apps/ck/lib/build/../ckcore.S:55:70: error: Could not find incbin file 'ckcore.ck'
.global __binary_ckcore_ck_start; __binary_ckcore_ck_start:; .incbin "ckcore.ck"; .global __binary_ckcore_ck_end; __binary_ckcore_ck_end:
                                                                     ^
make[5]: *** [ckcore.o] Error 1
make[4]: *** [build] Error 2
make[3]: *** [lib] Error 2
make[2]: *** [ck] Error 2
make[1]: *** [apps] Error 2
make: *** [/Users/seclorum/Documents/minocaOS/src/x86dbg/obj/os] Error 2

.. will close this issue, start a new one.

from os.

hi, today I still have the same stdio.h problem without s-u-p-e-r-t-r-a-m-p's fix. don't know if Linux toolchain has updated yet.

$ ./i686-pc-minoca-gcc --version
i686-pc-minoca-gcc (GCC) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

MD5 sum of the tools

$ md5sum minoca-tools-linux.tar.gz 
7fbac8719d287d22898b5c1f890ecadb  minoca-tools-linux.tar.gz

I am building on ARCH linux and Fedora

from os.

nvm, the linux toolchain hasn't updated yet. I checked the md5 on yesterday's download and this morning's download and are the same.

from os.

Re-opening until it gets confirmed as working on Linux (issue is fixed, imho, on macOS) ..

from os.

Can confirm. Worked on my arch and fedora machines with downloaded toolchain. However compiling toolchain has its own issues too.

from os.

I could build the toolchain and Minoca for x86dbg, x86qdbg and armv7dbg on Debian8.6/amd64.

Update: armv6dbg too...

from os.

from os.

@KawaniwaHikaru:

(yeti@kumari:11)/wrk/minoca$ cat /etc/debian_version 
8.6
(yeti@kumari:11)/wrk/minoca$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10) 

from os.

thanks @yeti, yean my default GCC is 6.2.1 and it reports a whole bunch of
error when cross-compiling GCC 4.9.2, I will use a docker container to
compile the toolchains.

On Thu, Nov 3, 2016 at 11:09 AM, yeti [email protected] wrote:

Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/minoca/os/issues/7#issuecomment-258226948, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABKwi5HAF5eidtxEnfyKnPdgrWEoJn9Tks5q6iNvgaJpZM4Kl938
.

Brian Ho
Lead Developer/Dev Op
Office: +1 (604) 229-1215
Mobile: +1 (604) 716-5645

Vandrico Solutions Inc. - Turning Your Data into Informed Action

This email and any attachments herein are intended for the named recipients
only and may contain confidential and/or privileged materials. Any
unauthorized copying, reviewing, dissemination or other use by a person
other than the named recipients of this communication is strictly
prohibited and decisions made on the basis of this recommendation are the
sole responsibility of the infringer. If you received this email in error
and/or are not a named as a recipient, please notify the sender and delete
all copies of this email immediately. Thank you.

from os.

Closing, confirmed working on Linux ..

from os.