Is the way I edit wiki okay?

dlarudgus20 · **Joined:** Sat Oct 26, 2013 4:14 am **Posts:** 36

I added some fixes for cygwin in http://wiki.osdev.org/GCC_Cross-Compiler#GCC.

However, is it okay? It's my first wiki-editing in my life, and I'm afraid now ..

sortie · **Joined:** Wed Mar 21, 2012 3:01 pm **Posts:** 930

No need to be afraid. At worst I would rollback your edit or fix it. If you are really in doubt, feel free to ask here ahead of time. It doesn't matter, any damage you can do can be easily undone - any contribution you make stays. There is no punishment for making errors when editing the wiki. :-)

Code:

# If you're in cygwin, you need to copy *.dll.a to *.a
cp /lib/libmpfr.dll.a /lib/libmpfr.a
cp /lib/libmpc.dll.a /lib/libmpc.a
cp /lib/libgmp.dll.a /lib/libgmp.a
cp /lib/libcloog-isl.dll.a /lib/libcloog-isl.a # if you have cloog or isl
cp /lib/libisl.dll.a /lib/libisl.a
cp /lib/gcc/i686-pc-cygwin/x.y.z/libgcc_s.dll.a /lib/gcc/i686-pc-cygwin/x.y.z/libgcc_s.a

Why is this needed? Why doesn't Cygwin do this itself? If this is truly needed, I don't mind having it here, but I am not too happy about instructions that work around bugs in Cygwin. Is the problem that you configured Cygwin wrong? Is this only used in some cases?

Could you shed a bit of light? I'm not a Cygwin user but this sounds very strange to me.

dlarudgus20 · **Joined:** Sat Oct 26, 2013 4:14 am **Posts:** 36

sortie wrote:

Why is this needed? Why doesn't Cygwin do this itself? If this is truly needed, I don't mind having it here, but I am not too happy about instructions that work around bugs in Cygwin. Is the problem that you configured Cygwin wrong? Is this only used in some cases?

Could you shed a bit of light? I'm not a Cygwin user but this sounds very strange to me.

Hum, I don't know the exact reason, but I guess it's just convention... ( ${dllname}.a => libfoo.dll.a )

Nable · **Joined:** Tue Nov 08, 2011 11:35 am **Posts:** 453

I think that this idea is wrong. Just think: if one uses gmp, mpfr, etc from cygwin's repo then all files are already in their place. If you are talking about the files that you've compiled on your own, then you shoudn't put them to system-wide /lib, /usr/lib and other directories like that.

Here's some kind of log of my actions when I've built gcc cross-compiler for the last time in Cygwin:

Code:

mkdir -p /opt/avr/bin
export PREFIX=/opt/avr
export PATH='/usr/local/bin:/usr/bin:/bin:/opt/avr/bin'
wget --passive-ftp ftp://sourceware.org/pub/binutils/snapshots/binutils.tar.bz2
tar -xvf binutils.tar.bz2
cd binutils-2.23.52
mkdir obj-avr
cd obj-avr
../configure --prefix=$PREFIX --target=avr --disable-nls
make && make install
cd ../../
wget --passive-ftp ftp://ftp.gmplib.org/pub/gmp-5.1.2/gmp-5.1.2.tar.lz
lzip -d -c gmp-5.1.2.tar.lz | tar -xvf -
cd gmp-5.1.2/
./configure
make
make check
make install
cd ..
wget http://www.mpfr.org/mpfr-current/mpfr-3.1.2.tar.xz
tar -xvf mpfr-3.1.2.tar.xz
cd mpfr-3.1.2
./configure --with-gmp=/usr/local --disable-shared
make
make check
make install
cd ..
wget http://www.multiprecision.org/mpc/download/mpc-1.0.1.tar.gz
tar -tvf mpc-1.0.1.tar.gz
cd mpc-1.0.1
./configure --with-gmp=/usr/local --with-mpfr=/usr/local --disable-shared
make
make check
make install
cd ..
wget --passive-ftp ftp://linux-mirror.no-ip.org/GNU/gcc/gcc-4.8.1/gcc-4.8.1.tar.bz2
tar -xvf gcc-4.8.1.tar.bz2
cd gcc-4.8.1
mkdir obj-avr
cd obj-avr
LDFLAGS='-L /usr/local/lib -R /usr/local/lib' ../configure --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local --prefix=$PREFIX --target=avr --enable-languages=c,c++ --with-dwarf2 --disable-doc --disable-shared --disable-libada --disable-libssp

Maybe there's also some kind of bad practice in this example but I've tried my best to do everything in an easy-reversable way, without any damage^W manual changes of the directories that are managed by packaged manager. Libs (that can be shared among cross-compilers) went to /usr/local, different cross-compilers went to /opt/$ARCH .

dlarudgus20 · **Joined:** Sat Oct 26, 2013 4:14 am **Posts:** 36

Nable wrote:

I think that this idea is wrong. Just think: if one uses gmp, mpfr, etc from cygwin's repo then all files are already in their place. If you are talking about the files that you've compiled on your own, then you shoudn't put them to system-wide /lib, /usr/lib and other directories like that.

No, although I use libraries from cygwin's repo, they're *.dll.a, not *.a. I've had some error due to it before...

Nable · **Joined:** Tue Nov 08, 2011 11:35 am **Posts:** 453

dlarudgus20 wrote:

No, although I use libraries from cygwin's repo, they're *.dll.a, not *.a.

Suddenly:

Code:

$ cygcheck -p 'mpfr\.a'
Found 0 matches for mpfr\.a

$ cygcheck -p 'mpfr\.dll\.a'
Found 3 matches for mpfr\.dll\.a
cygwin64-mpfr-3.1.2-1 - MPFR for Cygwin 64bit toolchain
libmpfr-devel-3.0.1-1 - A library for multiple-precision floating-point arithmetic with exact rounding (development)
libmpfr-devel-3.1.2-1 - A library for multiple-precision floating-point arithmetic with exact rounding (development)

dlarudgus20 wrote:

I've had some error due to it before...

If you can remember some details and way to reproduce your problems then it would be nice to report it as bug to cygwin developers. But local hacks (especially those you don') doesn't seem to be a good idea that can be suggested to other people.

Btw, Cygwin has some hacks with file extensions (for example, when you execute ./app it first tries ./app and (if it's not present) then ./app.exe) but `configure' scripts often takes such facts into account.
After all, my way is quite simple: forget about cygwin's lib{gmp,mpc,mpfr}-devel, download latest stable versions with gcc, then build and install them to some dedicated directory (one additional advantage: your cross-compiler won't be broken by updates). Btw, when you build libs by yourself, they have right names:

Code:

$ find /usr -name \*mpfr\*.a
/usr/local/lib/libmpfr.a

jnc100 · **Posted:** Sat Jun 21, 2014 9:56 am

Indeed the Cygwin versions are called *.dll.a (in the *-devel packages), however this is not a problem as the ld bundled with Cygwin knows that when passed '-lgmp' it looks for libgmp.dll.a and compiles successfully. I have just checked this on a simple test:

Code:

gmp.c:
#include <gmp.h>

int main()
{
    mpz_t integ;
    mpz_init(integ);

    return 0;
}

gcc -o gmp gmp.c -lgmp

and also by recompiling gcc (4.8.2) without your fixes and it works fine (with the Cygwin packages for gmp/mpfr/mpc).

I have taken the liberty of reversing your wiki changes.

Regards,
John.

dlarudgus20 · **Joined:** Sat Oct 26, 2013 4:14 am **Posts:** 36

Nable wrote:

After all, my way is quite simple: forget about cygwin's lib{gmp,mpc,mpfr}-devel, download latest stable versions with gcc, then build and install them to some dedicated directory (one additional advantage: your cross-compiler won't be broken by updates).

Wherever we install cross-compiler, we need lib{gmp,mpc,mpfr}-devel, don't we?

Nable wrote:

Btw, when you build libs by yourself, they have right names:

Code:

$ find /usr -name \*mpfr\*.a
/usr/local/lib/libmpfr.a

Um? In my case, it isn't. While I use gmp,mpc,mpfr from cygwin's repo, I build cloog-0.18.1 myself (because the version of cygwin's cloog was too low - when I install cygwin), but it also generated *.dll.a.

dlarudgus20 · **Joined:** Sat Oct 26, 2013 4:14 am **Posts:** 36

jnc100 wrote:

Indeed the Cygwin versions are called *.dll.a (in the *-devel packages), however this is not a problem as the ld bundled with Cygwin knows that when passed '-lgmp' it looks for libgmp.dll.a and compiles successfully. I have just checked this on a simple test:

Code:

gmp.c:
#include <gmp.h>

int main()
{
    mpz_t integ;
    mpz_init(integ);

    return 0;
}

gcc -o gmp gmp.c -lgmp

and also by recompiling gcc (4.8.2) without your fixes and it works fine (with the Cygwin packages for gmp/mpfr/mpc).

I have taken the liberty of reversing your wiki changes.

Regards,
John.

You're right - I did it myself, and it makes no errors.

However, when building cross-compiler, it mess up.. I don't know why - as someone says, it looks like bug..

sortie · **Joined:** Wed Mar 21, 2012 3:01 pm **Posts:** 930

Did you do something special regarding ld? Supposedly it is able to detect and link against .dll.a files? Can you confirm or deny this?

jnc100 · **Posted:** Sun Jun 22, 2014 9:46 am

dlarudgus20 wrote:

However, when building cross-compiler, it mess up.. I don't know why - as someone says, it looks like bug..

What is the error message exactly? Is it during the configure or make phase?

In addition, what version of gcc are you trying to build, and what version of gcc/ld are you trying to use to build it?

Regards,
John.

dlarudgus20 · **Joined:** Sat Oct 26, 2013 4:14 am **Posts:** 36

jnc100 wrote:

dlarudgus20 wrote:

However, when building cross-compiler, it mess up.. I don't know why - as someone says, it looks like bug..

What is the error message exactly? Is it during the configure or make phase?

In addition, what version of gcc are you trying to build, and what version of gcc/ld are you trying to use to build it?

Regards,
John.

Um, maybe make phase, and the error occurs in some versions of gcc/ld (I remember it occurs in 4.8.2/4.8.3 gcc)

I don't remember exact toolset... maybe I shall re-try it on clear machine and report it..

dlarudgus20 · **Joined:** Sat Oct 26, 2013 4:14 am **Posts:** 36

Now, I'm doing it on clear machine with latest cygwin, and it goes well without this. It may be bug.

However, this machine is winxp, and I remember the copying is required on win7/8. Strictly speaking, we need experiment more..

jnc100 · **Posted:** Sat Jun 28, 2014 1:54 pm

For me it also works fine on Win7 and 8 (64-bit versions with Cygwin64).

Regards,
John.

OSDev.org

Is the way I edit wiki okay?

Who is online