Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

you should replace all the if [ "${CT_*}" = "n" ] by if [ ! "${CT_*}" = "y" ] #14

Open
class101 opened this issue Feb 4, 2014 · 5 comments

Comments

@class101
Copy link

class101 commented Feb 4, 2014

Better replace because for example when you do

if [ "${CT_MULTILIB}" = "n" ]; then

and in the config file

CT_MULTILIB is not set

CT_MULTILIB is indeed to n but the condition will not be executed

It's an example of what I mean conflict when using your build.sh patch because by supporting multilib, you break the no multilib or ln -s support

@class101
Copy link
Author

class101 commented Feb 4, 2014

Addition: Btw I know you don't want to support ln -s but anyway to support it you should do instead

--- scripts/crosstool-NG.sh.in.orig 2014-02-03 22:10:11.752895600 +0100
+++ scripts/crosstool-NG.sh.in  2014-02-03 22:11:47.280186700 +0100
@@ -352,8 +352,10 @@
             "${CT_SYSROOT_DIR}/usr"         \
             "${CT_PREFIX_DIR}/${CT_TARGET}" \
         ; do
+        if [ ! -h "${d}/lib32" ]; then
             CT_DoExecLog ALL ln -sf "lib" "${d}/lib32"
             CT_DoExecLog ALL ln -sf "lib" "${d}/lib64"
+        fi
         done
     fi

@mingwandroid
Copy link
Collaborator

Good point with ! CT_MULTILIB = y, but I don't understand why you added a check before ln -sf?

If it already exists then you must have started a build in an existing build folder, which would be a bad thing to do.

@class101
Copy link
Author

class101 commented Feb 5, 2014

this one not really required but this was when I was testing the non sysroot option, ${CT_PREFIX_DIR}/${CT_TARGET} = CT_SYSROOT_DIR and it was causing en error attempting to create the same link twice so I added this as a safe check

But instead I prefer to use a sysroot = prefix so I put everything in top levels so I changed the path a bit more now, I just have one level of subfolders and on windows target, mingw is a link to the tuple dir , on linux /usr also links to the tuple dir and everything in the tuple dir link back to root include lib folder

    if [ "${CT_USE_SYSROOT}" = "y" ]; then
        #CT_SYSROOT_REL_DIR="${CT_SYSROOT_DIR_PREFIX:+${CT_SYSROOT_DIR_PREFIX}/}${CT_SYSROOT_NAME}"
        CT_SYSROOT_DIR="${CT_PREFIX_DIR}"
        CT_DEBUGROOT_DIR="${CT_SYSROOT_DIR}"
        CT_HEADERS_DIR="${CT_SYSROOT_DIR}/include"
        CT_SanitiseVarDir CT_SYSROOT_DIR CT_HEADERS_DIR 
        BINUTILS_SYSROOT_ARG="--with-sysroot=${CT_SYSROOT_DIR}"
        CC_CORE_SYSROOT_ARG="--with-sysroot=${CT_SYSROOT_DIR}"
        CC_SYSROOT_ARG="--with-sysroot=${CT_SYSROOT_DIR}"
        LIBC_SYSROOT_ARG=""
        # glibc's prefix must be exactly /usr, else --with-sysroot'd gcc will get
        # confused when $sysroot/usr/include is not present.
        # Note: --prefix=/usr is magic!
        # See http://www.gnu.org/software/libc/FAQ.html#s-2.2
    else

This would be awesome you support custom sysroot directories

@class101
Copy link
Author

class101 commented Feb 5, 2014

btw I haven't scanned much = "n" but I haven't looked at case for example, maybe there are so case you look for a "n"

@mingwandroid
Copy link
Collaborator

We don't want to extend the scope of this project too much (which is cross compilation on the 3 biggest desktop OSes targeting those same OSes + iPhone). We already have a very hard time worrying about merging back to upstream!

I suggest if you have changes that are not specifically related to the scope of this project then you should submit them to the crossgcc mailing list.

mingwandroid pushed a commit that referenced this issue Jan 9, 2015
libc/glibc: install obsolete RPC for both eglibc and glibc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants