From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7425 invoked by alias); 19 Aug 2011 20:56:23 -0000 Received: (qmail 7417 invoked by uid 22791); 19 Aug 2011 20:56:22 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from tschetwerikow.v9g.de (HELO tschetwerikow.v9g.de) (217.92.164.63) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Aug 2011 20:56:07 +0000 Received: from localhost (localhost [127.0.0.1]) by tschetwerikow.v9g.de (Postfix) with ESMTP id 0AADB1745B7B; Fri, 19 Aug 2011 22:56:00 +0200 (CEST) Received: from tschetwerikow.v9g.de ([127.0.0.1]) by localhost (tschetwerikow.boxberg.lan [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPWU5BqypoFD; Fri, 19 Aug 2011 22:55:58 +0200 (CEST) Received: from mikulin.boxberg.lan (mikulin.boxberg.lan [10.0.1.253]) by tschetwerikow.v9g.de (Postfix) with ESMTPSA id 3F1B51745B6D; Fri, 19 Aug 2011 22:55:58 +0200 (CEST) Subject: Re: gdb problem Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Titus von Boxberg In-Reply-To: <201108192000.13342.yann.morin.1998@anciens.enib.fr> Date: Fri, 19 Aug 2011 20:56:00 -0000 Cc: crossgcc@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <6042768C-A17C-41CC-B892-016829F21F6C@v9g.de> References: <201108190032.26721.yann.morin.1998@anciens.enib.fr> <201108192000.13342.yann.morin.1998@anciens.enib.fr> To: "Yann E. MORIN" X-IsSubscribed: yes Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org X-SW-Source: 2011-08/txt/msg00080.txt.bz2 Am 19.08.2011 um 20:00 schrieb Yann E. MORIN: > Titus, All, >=20 > On Friday 19 August 2011 09:09:27 Titus von Boxberg wrote: >> Am 19.08.2011 um 00:32 schrieb Yann E. MORIN: >>> On Wednesday 17 August 2011 23:31:36 Titus von Boxberg wrote: >>>> -static is not supported on Darwin. >>>=20 >>> So -static is not supported on Darwin? So why on Earth does the ncurses= from >>> Macports install static versions of the libraries? >> Passing -static is not equivalent to linking to an archive file. >=20 > I know, but it seems to me that creating static libraries is possible on > Darwin, and thus there would be a way to ask for staticaly linking an > executable. There are 3 things intermixed here. 1) You can link to static libraries. E.g. my software is built as static libs. No problem to link them in. But see below. 2) You cannot produce a statically linked executable. Actually, I do not know exactly why that is the case, viewed on Mach-O bit level (and strange enough, that lack of knowledge doesn't bother me ;-). You always have to produce an executable that requires the dynamic linker/loader combo to start a process from it. Or the other way round: no program can be started without the dynamic linker/loader. 3) A third thing comes in from this particular problem: you cannot select a static lib when a dynamic lib is found in the same path. You have to play tricks to get that done, as given in http://developer.apple.com/library/mac/#qa/qa1393/_index.html =46rom `man ld`, and points 1) and 3) above results that the elf-ld compatible command line =85 -static -lnicelib -dynamic -lblah =85 does not = work. The only ways to achieve the equivalent of this command line would be to ensure that - libnicelib is present only as an archive file but not as a dylib, or - the linker search paths are made up as outlined in Apple's reference. In short: Drop the idea of static linking as completely as possible on Darw= in. Time's a too precious resource for that crap. > No, absolutely not. I'll learn to post-pone such mails in the future, so > I can be in a more relaxed state before I post. Apologies to anyone who > might have resenseted offense=85 No offense taken. I just wanted to know whether you are restricting ct-ng to Linux. >=20 >> If the former, then why not simply tackle those problems and add a fix? >=20 > Sure, sure. It's just that I am a bit lost here, as I do not have the > slightest idea on how we should do things on Darwin. ?? The things I tested worked very well. No need to be pessimistic. As I wrote early 2010, compared to old crosstool and earlier tool chains, things went very smoothly and the patches necessary for BSD/Darwin were ridiculously small. Darwin, may it be idiosyncratic in this or the other way, still is a UNIX compliant system. I never tried uclibc, so I'm not surprised that problems arise. In general (not only for Darwin) I'd say: Try to be as much UNIX/Posix compliant as possible. Do not use the more or less unnecessary GNU extensions. At least within ct-ng this rule can be easily followed. Where the problems following this rule outweigh the benefit, add the GNU tool as a prerequisite. >=20 > On the one hand, I'd rather not have ugly kludges in the code to handle > Darwin, or we could see a proliferation of those kludges, not only for > Darwin, but also other OSes. Think Cygwin and mingw for example, which > have their own idiosyncracies and limitations in their own subtle ways. What is a kludge, here? You can also view it the other way round. If you use nonportable features of one platform (like static linking) then this might be regarded as a kludge (just like I still regard it in this particular case). After all, if I remember correctly, you introduced static= linking because you fear that (libstd)c++ undergoes ABI changes and the Linux distr= os cannot handle that (which I feel is an absolutely legitimate concern, nonetheless all this is an Evil Kludge from GNU Hell). > On the other hand, I'd like to have support for as many systems as > possible (World Domination, anyone? ;-)), while not being capable or > able to get my hands on said systems. I'm afraid that even World Domination has to be gained in small steps. divide et impera. For continuous support of host OSs other than linux, here Darwin, I'd recommend that there is a set of configs identified that are expected to work on that OS / Darwin. I could add mine to that set. Maybe rename samples directory into "samples-linuxhost", and add other samples directories for the particular host OSs. We already know (and Guylhem just experienced) the build systems of the tool chain parts are only portable to a certain extent. Introducing a host OS specific set of working examples would mean that one cannot expect to have ct-ng build any tool chain combination (in the general/linux samples directory) out of the box on non-GNU/Linux systems, but there is at least a (smaller) starting point the user can rely upon. How do you handle it now with older configs that eventually break on newer Linux host systems? Or with now more or less unsupported things like OABI for ARM? Do you silently delete the samples as the older tool cha= in parts get dropped from menuconfig? Or just add a "deprecated/broken" note? Do you drop anything at all? Just do it the other way round for Darwin/other OSs. Furthermore, you might also add patches directories specific to the host OS; then maybe patches (like mine for eglibc, or the coming ones for uclibc) could be introduced more quickly because there is no danger that things get broken on Linux. Do you have scripts for regular automatic tests of the samples? Then - if the tool chains working on Darwin are identified - testing at least the build steps (omitting menuconfig et.al.) could be done automatically. Just an idea. Anyway, Guylhem sent me his .config. I'll try the next days to get things to work. Regards Titus -- For unsubscribe information see http://sourceware.org/lists.html#faq