Re: Bash security issue
On Mon, 29 Sep 2014, Paul Eggert wrote: which is caused by a widely-distributed Bash fix that overreacted to the bug and is causing me more problems than the bug did. Let's not do something like this with Autoconf. Hmm, that overreaction is currently mitigating two undisclosed RCE bugs in bash: http://lcamtuf.blogspot.co.nz/2014/09/bash-bug-apply-unofficial-patch-now.html http://www.itnews.com.au/News/396256,further-flaws-render-shellshock-patch-ineffective.aspx Which is going to trigger a third round of shellshock security updates (because mitigated is not fixed) soon enough, at which point a lot of people might well decide to patch bash to remove the functionality entirely. NetBSD and FreeBSD already did. But this doesn't affect autoconf, really. What _could_ affect autoconf is that bash can add crap to the environment which is illegal under POSIX, because bash functions are not as restricted as POSIX environment variables. Sorry, I don't have the link to the relevant oss-sec post right now. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: A Closer Look at GNU AutoTools
On Fri, 05 Sep 2014, Hartmut Holzgraefe wrote: * the good old Goats Book which is also available online, and seems to have received an update lately: https://www.sourceware.org/autobook/autobook/autobook_toc.html I still refer to my paper copy every once in a while, but by now that one's so old that a lot of things need to be cross-checked against current autotools documentation This one is available under the OPL v1.0 with no extra options (http://opencontent.org/openpub/). It was updated in 2006 to address autoconf-2.59, automake-1.9.6, libtool 1.5.22. This _should_ be fresh enough to be useful. If someone looks it over and states that it is indeed useful for recent autotools, I believe a pointer to this book should be added to the autotools (autoconf, automake, libtool) websites. In fact, the Debian project had it packaged in non-free for quite a while[1]. It was removed in 2008, because non-free was carrying the unofficial 1.4.4 edition from http://mdcc.cx/autobook/, which is obsolete as it was never updated to the 1.5 official release. [1] The Debian DFSG when applied to documentation is more restrictive than the GNU free documentation license guidelines. The autobook complies to the GNU requirements for a free documentation license, at least according to http://www.gnu.org/licenses/license-list.html#FreeDocumentationLicenses since no options of the OPL were exercised in the autobook license. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 20 May 2013, Pavel Raiskup wrote:
+cc config-patc...@gnu.org, Ben Elliston b...@air.net.au
IME, it is much better when any override mechanism make use of
environment variables.
Yes, it was mentioned multiple times in this thread already and it was
always forgotten. Please consider this approach.
One thing was not mentioned here - if there was a CONFIG_GUESS/CONFIG_SUB
environment variables, what would be the consequences of having it solved
directly in config.{guess,sub} files?
I mean, if there was defined CONFIG_GUESS environment variable, the
config.guess could try to call 'config.guess' file somewhere in $PATH?
pros: we are able to easily patch also old packages (no-need to
autoreconfigure)
Works for me. But we [distros] do want to mandate autoreconf anyway in the
general case: it is the *only* way to keep upstream honest about the much
hated build system not bitrotting until it decides to blow up right when we
need it for a security update.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Sat, 18 May 2013, Paul Wise wrote:
On Fri, 2013-05-17 at 16:05 -0300, Henrique de Moraes Holschuh wrote:
Yes. It would have been really useful if autofoo used whatever is in
/usr/share/misc, unless there is a config.sub.override or
config.guess.override file in the source directory (or even better,
something pointed to by environment variables), and deprecate
source-directory config.guess and config.sub.
My original patch didn't allow overrides, here is an updated one.
IME, it is much better when any override mechanism make use of environment
variables. These are very easy to set per-build, per-user and system-wide,
unlike system-wide files and even per-project files.
It would be enough for the environment variables, when present, set the name
of the override files, and default to local config.{sub,guess}.override or
whatever when the variables are not set.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Thu, 16 May 2013, Paul Wise wrote: On Wed, 2013-05-15 at 16:30 +0200, Thomas Petazzoni wrote: On Tue, 14 May 2013 23:53:44 -0400, Mike Frysinger wrote: yes, Gentoo fixed this for every package in our tree like 9 years ago FWIW, we do the same thing in Buildroot Yes, it is a very common hack in all of the distros. It would be nice if that wasn't necessary in the first place though. Yes. It would have been really useful if autofoo used whatever is in /usr/share/misc, unless there is a config.sub.override or config.guess.override file in the source directory (or even better, something pointed to by environment variables), and deprecate source-directory config.guess and config.sub. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 08 Oct 2012, Russ Allbery wrote:
Personally, I've already started converting every package I maintain that
uses Autoconf to using dh_autoreconf during the build. I wonder if that
isn't a better long-term solution for Debian. config.guess/config.sub
have caused the most frequent problems, but we've had problems in the past
from old versions of Libtool as well, and dh_autoreconf resolves the
entire problem (at least for packages for which it works).
Paul, separately, if you haven't already, could you request that the
Lintian checks for outdated config.guess/config.sub be updated for
whatever version you need for arm64? We could also recommend
dh_autoreconf at the same time, which might resolve a lot of these
problems going forward.
Well, as far as I am concerned, we should axe from the [next] Debian stable
distro anything that doesn't retool completely before the build, IMO just
updating config.sub/guess is not nearly enough.
That said, Debian rules for packages *really* won't help a large class of
people: those who are not doing Debian package work...
And BTW, I am perfectly fine with issuing debian-stable updates to
autotools-dev (the Debian package that contains the /usr/share/misc/
config.{sub,guess}), but someone has to convince the release managers that
this is acceptable. We _really_ should do this, since people do develop
software using Debian...
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: just one of a million reasons why autoconf is a worthless piece of shit (2)
On Sun, 16 Mar 2008, Paul Smith wrote: Second, if you think you can write your own config script that will be portable to even a small fraction of the systems that an autoconfiscated LOL! I think you wanted to say autoconfed/autoconfied here. Autoconfiscated makes it sound like you agree with the troll :) actually _produced_ anything better. Odd. There ARE alternatives. I think they're just as bad (not worse, not better) than autoconf, though. And, if you don't care about your project being portable, then indeed: why are you even bothering with autoconf? Why, it is trendy! -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: x86_64 and x86 userland
On Tue, 03 May 2005, Russ Allbery wrote: Harald Dunkel [EMAIL PROTECTED] writes: Ralf Wildenhues wrote: I have a question regarding systems with more than one ABI, specifically x86_64. If you consider for example the Debian distribution which has a x86_64 kernel, but a completely x86 userland, config.guess still gives you x86_64-unknown-linux-gnu as output. (I have been told this, but not tried it myself). What do you mean by a completely x86 userland? I am running Debian (amd64) on my PC at home. There are no 32bit applications on it. AFAIK this is different to some other major Distros claiming amd64. There are two ways of running Debian with amd64. Your way is the full separate architecture approach, which has (unofficial but pretty solid) support for sarge. The other way is to use the standard i386 architecture but install an amd64 kernel and the amd64-libs package, which I think is what Ralf is talking about. Well, as long as gcc and dpkg-architecture think it is running under a x86_64 (which *is* 64-bit in Debian), then the only sane config.guess output will be x86_64-something. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: OK to distribute autoconf.texi under the GPL too?
On Sun, 19 Dec 2004, Paul Eggert wrote: One approach that Autoconf could take is to provide a special exception so that any sample code copied from the documentation is licensed under the GPL or LGPL rather than GFDL. Thanks for this suggestion. At the end of this message is a proposed patch along those lines. Would this patch be enough to satisfy the Debian folks? I will submit it to debian-legal when you arrive at the final form of the patch, along with the following question: Would this patch solve the current GPL/GFDL incompatibility issues on autoconf? This is an orthogonal question to how the GFDL relates to the DFSG, so please stay on the topic at hand: Does it solve the GPL/GFDL incompatibility in the special case of autoconf, or not? If not, what else needs to be done to solve the GPL/GFDL compatibility issue for autoconf? Adding GFDL documents back to Debian depends on another issue, though, and that one will be decided only after Debian Sarge is released. Changing the GFDL would take more work. For now, how about if we start with Autoconf? If the result seems to work well in practice, then we can take it to the GFDL level. That would be very very good news. Please contact Benjamin Mako Hill [EMAIL PROTECTED], he can position you on how the Debian and the FSF talks about the issue are going, and what to expect from both sides. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: OK to distribute autoconf.texi under the GPL too?
On Sun, 19 Dec 2004, Roger Leigh wrote: However, the manual is still licensed under the terms of the GFDL, a licence which is not considered to meet the requirements of the Debian Free Software Guidelines. Therefore I believe it is not possible to Debian-legal (and many Debian developers) consider the GFDL and the DFSG to be incompatible. BUT this is on hold until Sarge ships, and GFDL documents are freely allowed in Debian Sarge. The autoconf maintainer may, or may not decide to have the GFDL documents back for Sarge... but I do believe the positive response shown on this thread could persuade him to add the docs back for Sarge. In any case, if he does not add the docs back, I will maintain them in a separate package. The whole issue of GFDL and Debian will take a head after Sarge releases. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: OK to distribute autoconf.texi under the GPL too?
On Fri, 17 Dec 2004, Bob Friesenhahn wrote: cut-n-paste them into their GPLed code. There more arguments; please see http://people.debian.org/~srivasta/Position_Statement.html for The GFDL is troubling to some, however, the GPL applies to *programs* so it is not an appropriate license for documentation. Unless the Many people (including myself) believe that essential documentation that is always shipped alongside a program *IS* part of the software, and thus it must not suffer additional restrictions than those specified by the GPL license. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: OK to distribute autoconf.texi under the GPL too?
On Fri, 17 Dec 2004, Paul Eggert wrote: Roger Leigh of the Debian project asked whether we could dual-license autoconf.texi, so that it could be distributed under the terms of either the GFDL or the GPL. One of his arguments is that the manual And, meanwhile, the texinfo docs were removed from Debian. I have uploaded the autoconf-nonfree package that generates autoconf-doc to non-free (that isn't Debian, but it is usually available alongside Debian), so that the docs are available until the issue is fixed in a better way and the documentation can make it back to the main package. autoconf-nonfree has not made it through Debian's new package queue yet, so I can still request that it gets removed without any fuss. I will be paying close attention to this thread. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: svn copy conflicts with autotools ?
On Wed, 01 Dec 2004, Eric PAIRE wrote: 3) I have set up a tag with 'svn copy' so that the tagged version is the exact copy of the version in the 'trunk' directory. 4) Another user gets the tagged version with a 'svn co' and runs 'configure' on it. And now ... As it was once so eloquently explained to me by a senior Debian developer when I asked exactly the same question (but for CVS, since Subversion didn't exist yet): If you're doing that, you're weird. Go away. The translation for that would be: Why the heck are you keeping auto-generated files in a RCS system? Get them out of there, they do NOT belong in the repository! Add a run-this-on-checkout script and proper rules to the makefiles to run the autotools sequence if the autotools files are not yet available. As for a bad autotools setup on the build system, well, document properly what the build system has to have installed for the development versions. Anyone doing development has to be at least capable of a proper build system setup, no? When you generate a release, run autotools before you make a tar.bz2/tar.gz/.cab/whatever file that you're going to distribute. This way, all the autotools scripts are already built and have correct timestamps inside the distribution archive. Normal users won't need to bother with autotools configs, then, unless they muck with Makefile.am, configure.in or something else like that. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: svn copy conflicts with autotools ?
On Wed, 01 Dec 2004, Stepan Kasal wrote: On Wed, Dec 01, 2004 at 10:13:45AM -0200, Henrique de Moraes Holschuh wrote: If you're doing that, you're weird. Go away. The translation for that would be: Why the heck are you keeping auto-generated files in a RCS system? Get them out of there, they do NOT belong in the repository! if you are that firm about the issue, you might try to convince Bruno to fix the node ``Files under CVS'' in the gettext manual. Hmm... just to make things clear, the weird thing was told TO me, not by me. It just happens that I think the person who said it was actually right on the issue (even if HE is the weird one IMHO). At least for CVS, it has been a major help in my experience to never register any autogenerated files on version control. Although I *do* keep history of all releases, so you could say I have some sort of version control of everything (including all autogenerated files) as far as released tarballs go. I learned from that text how can autotools and CVS/svn combined. Though I personally obey the rule ``no generated files in the RCS'', I seriously considered the other alternatives because of that text. I will read it, I am curious about what it says that could have such a strong effect on you. Maybe it can change my mind about the issue (but I doubt it)... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: svn copy conflicts with autotools ?
On Wed, 01 Dec 2004, Stepan Kasal wrote: On Wed, Dec 01, 2004 at 11:24:33AM -0200, Henrique de Moraes Holschuh wrote: On Wed, 01 Dec 2004, Stepan Kasal wrote: I learned from that text how can autotools and CVS/svn combined. Though I personally obey the rule ``no generated files in the RCS'', I seriously considered the other alternatives because of that text. I will read it, I am curious about what it says that could have such a strong effect on you. Maybe it can change my mind about the issue (but I doubt it)... No, it didn't have _strong_ effect. I just happened to learn about ``CVS in practice'' from that. So perhaps we should suggest that the text pushes the rule ``no generated files in the RCS'' more strongly. I see. I have also read the text, and really, the two keep autogenerated files under revision control rationales can IMHO be translated to if the project has a major mess for a development base, then you're better off with the autogenerated files under revision control. Of course, this assumes that one considers a very diverse development base a mess, which is not always true. OTOH, one can have all sort of architectures in the development base and STILL avoid version skew trouble, that's the whole point of autotools. IMHO in the way of a very diverse development base lies madness sooner or later anyway (and of a far worse kind than what a small version skew in autotools would cause), so one would do best by fixing the issue in the first place. As for the need to run something like ./autogen.sh when one gets a development version exported from the repository, well, that's what the INSTALL document is for, no? It is good practice to document all you need (including the version requirements for all build tools) in there anyway. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: svn copy conflicts with autotools ?
On Wed, 01 Dec 2004, Eric PAIRE wrote: everything, but you have to make these generated files ignored to your versioning system, and there should be a way to remove them easily. Maybe one of the automake targets do a full cleanup, I never tried to track that down. I never needed it. When I need a thruly pristine tree, I just export one from the revision control system, since *no* autogenerated files are in there at all. Docs you don't want changing under your feet such as COPYING are under version control, of course. But autotools do not touch that if it is already in place, so I don't think that counts for this thread. Anyway, I make sure to rm -f all autotools-generated files in the autogen.sh script BEFORE I regen the autotools stuff (except for the docs, such as COPYING, etc). This keeps stuff like install-sh always up-to-date ;-) *AND* I make sure to get a properly up-to-date GNU config (config.sub and config.guess) setup in at that time too, since THAT is a royal pain in the ass. already set up a tool which automatically removes the files generated by the autotools (perhaps this tool exists and I don't know about). Probably because you don't really need it most of the time, even if you keep the autogenerated files outside of version control... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Autoconf mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/autoconf
Re: config.sub/guess and --host/--build
On Fri, 11 Oct 2002, Ross Burton wrote: I am creating packages for Debian. The current practise at the moment if a package uses autoconf is to replace the config.sub and config.guess The current practice for Debian is in the autotools-dev package's README, and believe it or not, it changed a bit :) files in upstream with the latest version (which is available through the autotools-dev package) before building. Also, all Debian systems (running on 11 architectures) know what they are, so most packages also call configure with --host and --build arguments. Well, now I suggest in autotools-dev that we rm -f the stuff upstream includes, and symlink that to the ones provided by autotools-dev. Upstream rarely updates config.sub/guess enough anyway. I suggest we notify them once, and then leave it at their discretion (and don't use their supplied config.sub/.guess anymore). So, does using --host and --build mean that config.sub and config.guess will never be used? From a brief look at configure this appears to be config.sub always get called. the case, but is it a behaviour I can depend on to remain true in the future? Being able to ditch the config.sub and config.guess update mess would make things a lot easier... Read about the symlink method in the new autotools-dev package, and get the cyrus21-imapd package for an example of it in action (both from Debian unstable)... You never have to think about config.sub/.guess again. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: macros for rpath support
On Wed, 22 May 2002, Bruno Haible wrote: is it easy to _disable_ such feature? We have our own reasons for not wanting rpath information in our Debian packages Yes. You simply specify --prefix=/nonexistent at configuration time. At installation time you use make install DESTDIR=/tmp/destdir and then move the installed files from /tmp/destdir/nonexistent to /usr/local or wherever you want to have them. This is very un-optimal. Some programs embed the prefix path to find other files, and those would break quite hard... It would be best if we could tell your autoconf macros not to use rpath in a way guaranteed to have no side-efects, and mucking with something other macros use isn't it :-( But you should know that by doing this you push the LD_LIBRARY_PATH problem back to the user (unless you already deal with it in some way). We are a distribution. We _do_ make sure all our libs are in the right place, and reachable by the runtime linker without the need for user configuration. As I said, we have our own reasons to strip rpath from almost all libraries, and we do know what we are doing. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: macros for rpath support
On Wed, 22 May 2002, Bruno Haible wrote: Henrique de Moraes Holschuh writes: This is very un-optimal. Some programs embed the prefix path to find other files, and those would break quite hard. Oh, I gave an advice suitable for building relocatable binary packages. If that's not what you are doing, then please, can you tell why you don't want rpath entries in your shared libraries? I am not doing anything of the sort. We are usually downstream maintainers in Debian. But lots of upstream autoconf scripts use $prefix to set the default path for modules, for example. Please use your own 'disable rpath' option (maybe --without-rpath ?) so that it will not have side-effects when your autoconf macros get used by other people in their configure scripts. As for rpath in the distribution: We don't want rpath because rpath kills any possibility of relocatable _libraries_, and causes ABI headaches between distributions, for starters. Sometimes rpath is the right thing to do, but for a glibc Linux distribution, it isn't in the general case. If you _really_ are curious about the issue, refer to the Debian libc5 to libc6 transition issues, in our mailinglist archives. And think about cross-compiling issues, as well. What kinds of side effects of rpath have you experienced, that you would not have with LD_LIBRARY_PATH and similar workarounds? Total and utterly broken systems. And, if I was not being clear enough, we do NOT use LD_LIBRARY_PATH tricks in the distribution either. We use ld.so.conf and the ld.so linker itself only, so that the users can do whatever they want with rpath and LD_LIBRARY_PATH, and the local admin can change our defaults if he really knows what he is doing. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: macros for rpath support
On Wed, 22 May 2002, Alexandre Duret-Lutz wrote: Henrique == Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: Henrique We use ld.so.conf and the ld.so linker itself only, Wouldn't it be enough to teach `config.rpath' to *not* output `-rpath DIR' when `DIR' is already searched by `ld.so'? Like Libtool does (see `$sys_lib_search_path'). No. First, ld.so may search stuff libtool scripts are not aware of. Second, ld.so.conf may not have been modified yet at package build time. Using runtime data to compile packages has too many caveats to be done lightly. At the very best, it fucks up crosscompilation scenarios. Third, trying to be too clever results in stupid tools that cannot be told to do the right thing when you know better. FYI libtool has a terrible past record on rpath handling. Many of our porters hate libtool with vengeance (or worse), and not many people I've talked to that are downstream for libtool-using packages like it either. So, *please* don't overengineer it. Just give us a --without-rpath switch that actually works, without any clever tricks that are fated to bring even more pain and suffering to Earth. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: macros for rpath support
On Wed, 22 May 2002, Bruno Haible wrote: OK, I see. You are building non-relocatable packages in general, but still want libraries to be relocatable in case of major system surgery, and the /etc/ld.so.conf file is completely satisfactory for your purpose. Right? Yes. I think a configure option --without-rpath is completely adequate for this case and can be added to the macros with very little effort. Thank you! That will be very appreciated by our maintainers and porters. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: macros for rpath support
On Tue, 21 May 2002, Bruno Haible wrote: So I set out and realized in gettext-0.11.2 a solution of the LD_LIBRARY_PATH [...] Weird as it may sound, is it easy to _disable_ such feature? We have our own reasons for not wanting rpath information in our Debian packages (which are beyond the scope of this list). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Recent config.guess versions fail to recognize i?86-pc-linux-gnu
On Sat, 13 Apr 2002, Phil Stracchino wrote: I've been wondering for some time why it is that recent software packages are unable to identify the system type on my otherwise unexceptional i586-pc-linux-gnu machine. I just poked into config.guess and found the problem. [...] case $ld_supported_emulations in This code doesn't even exist in recent enough config.guess. You must update from CVS, and while at it get your distribution to do it too. What is the output of config.guess -t ? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Recent config.guess versions fail to recognize i?86-pc-linux-gnu
On Sat, 13 Apr 2002, Phil Stracchino wrote: I should probably have said config.guess from recent software packages. gcc-3.0.4's, which works, reports 2001-06-05 in response to config.guess -t. id3lib's, for a counter-example, ignores -t and returns i586-pc-linux-gnu after patching or nothing at all before. Foolish of me, I suppose, to assume that the latest version of a software package under active development would have an up-to-date config.guess. You cannot trust even distributions to do it always right. Debian is the only one I am aware that tries to do so, and that is for some loose definition of 'try'. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: --build and --host
On Mon, 04 Mar 2002, Akim Demaille wrote: Henrique == Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: Henrique It also means Debian will need to fork config.guess Henrique permanently so as to force autoconf stuff to build using the Henrique correct host arch (since there seems to be no way to Henrique sepecify a build architecture without entering Henrique cross-compiling mode or risking weird sidefects). Did I get Henrique that right? I don't understand what you mean here. configure is one thing, config.guess is another. config.guess is already cross-compilation proof: its task is to guess the *build* machine, and it does by being independent of the cross-compiler. Well, it goes more or less like this: we know beforehand the build and host machine architectures, and often config.sub or config.guess need an update to avoid breakage when those archs are very new. A recent breakage in config.guess for MIPS and MIPSEL got the ball rolling (suddenly nearly all GNU autoconf programs were broken in two archs, near release, because of a script we should not even need to run in Debian to begin with). And, as for Autoconf, passing --build, changes the build machine without entering cross-compilation. That is the solution I am proposing system-wide [for Debian] right now: always set --build (for autoconf 2.52+) or --host (for autoconf 2.13), using the known-good architecture. Set --host (for 2.52+) or --build (for 2.13) as well if we are doing cross-compilation. Apparently, this is enough and I was mistaken about the need to modify config.guess. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: --build and --host
On Thu, 28 Feb 2002, Akim Demaille wrote: Hi! Sorry for not having answered before, I lost this thread in the mass the others :( Heh, ok It was decided to make this move at the same moment as the chain of defaults (which was fairly incoherent) was fixed Because of the chain of defaults, many bizarre chunks of code were left to assist people making the transition But, as was to be expected, these pieces of code augmented the confusion, as configure answers incoherently to different stimuli :( Not to mention wrong documentation Anyway, this is exactly what I wanted: a clear, official and final position on the issue Now I can act on the issue, at least It also means Debian will need to fork configguess permanently so as to force autoconf stuff to build using the correct host arch (since there seems to be no way to sepecify a build architecture without entering cross-compiling mode or risking weird sidefects) Did I get that right? -- One disk to rule them all, One disk to find them One disk to bring them all and in the darkness grind them In the Land of Redmond where the shadows lie -- The Silicon Valley Tarot Henrique Holschuh
Re: --build and --host
On Thu, 28 Feb 2002, Steve M Robbins wrote: I think you just want to specify --build, no? *I* would be happy enough specifying --build (for autoconf 252+), and sending fix for any eventual breakages that causes to upstream But one can count on someone getting all pissed in d-devel that we are not fixing the whole issue at once, or that 'this entire stuff does not change anything in *my* packages, why should I care' So, it will have to wait until Debian woody is out Why do you think configguess has to be modified? I am not 100% sure about this yet It _is_ the easiest, change-almost- nothing quick-fix way Mind you, we have a canonical source for the host arch when building Debian packages, that is given by some of the output of dpkg-architecture If configguess always returns that, configure scripts generated by 213 and 252+ will just assume a native build with the arch we want for ia32, and will not break on other archs either That will not fix the entire problem (no crosscompiling support), but it is a quick fix I can get inside all the packages that need to be updated for MIPS* before release, and inside all the packages that use GNU config in time for the woody+1 Debian release (Such a modified configguess script will also be faster, less prone to breakage, and will never cause trouble on recent archs that always require the config* scripts to be updated With some luck, anyway) It is also woody+1 material, I think And if you want to set up to allow cross compiling, you can do that by looking at DEB_HOST_GNU_TYPE, as suggested by Marcus Brinkmann [http://listsdebianorg/debian-devel/2002/debian-devel-200202/msg00353html] --- though he got host and build reversed The --host and --build needing to be reversed according to whichever autoconf got used to produce the configure script is a major pain in the *** in this whole issue, and what send me to this list to begin with :) I still think that you can fix the build problem and leave host until later [http://listsdebianorg/debian-devel/2003/debian-devel-200202/msg00832html] I am aiming to get the entire, proper, safe fix that includes crosscompiling support and is not an ugly hack (whatever that solution ends up being) for woody+1, which gives me enough time to try to understand all the angles of the problem Right now, I think a Debian-aware configguess plus a small wrapper that sets --host and --build for cross-compilation is the answer You will be happy to know that I am smuggling the wrapper (that currently does nothing other than call the configure script) into woody so that people won't be able to complain that we are breaking source-compatibility with woody if we go with your suggestion of a wrapper It is called /usr/bin/configurewrapper, and belongs to the autotools-dev package right now Yes, the name is ugly on purpose (but if you have any better ideas that don't start with dh_, send them my way I can try to smuggle in that change in a critical priority upload) -- One disk to rule them all, One disk to find them One disk to bring them all and in the darkness grind them In the Land of Redmond where the shadows lie -- The Silicon Valley Tarot Henrique Holschuh
Re: Why was handling of program_prefix changed?
On Thu, 14 Feb 2002, Ralf Corsepius wrote: Am Mit, 2002-02-13 um 20.09 schrieb Henrique de Moraes Holschuh: need to be modifed. We would also like to tell configure what arch to build for directly while at it (even when not crosscompiling), to avoid the config.guess call. = Just explicitly set host == build That is what we were going to propose as a Debian-wide fix, and it is also what the 2.52 manual tells us to do. BUT a previous message in this thread, stored at http://sources.redhat.com/ml/autoconf/2002-02/msg00059.html seems to imply otherwise :( THAT is why I am asking for a definitive statement about the future of crossbuilding in autoconf for the foreseable future (i.e 2.52, 3.x)... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Why was handling of program_prefix changed?
Hello Akin, autoconf developers, On Mon, 11 Feb 2002, Akim Demaille wrote: Ian Akim Demaille [EMAIL PROTECTED] writes: But wrt prefix_program, if *you*, Ian, tell me this change is wrong (as opposed to good but implies more work elsewhere), then I'm revert that bit. Ian I was accepting that this change was made and will not be undone, Ian and I was pointing out the additional work which needed to be Ian done by somebody. But I don't know who that person is. Until Ian the work is done, gcc will not be able to adopt the new autoconf. Well, right now in autoconf 2.52, part of the code works just as currently documented (i.e. crosscompiling is activated if --build and --host differ): # FIXME: should be removed in autoconf 3.0. if test x$host_alias != x; then if test x$build_alias = x; then cross_compiling=maybe echo $as_me: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. 2 elif test x$build_alias != x$host_alias; then cross_compiling=yes fi fi Currently we have some major breakage in Debian re. crosscompilation, and we really would prefer to fix it only once (since it does mean changing all packages that use autoconf, and that's quite a lot). That means we have thousands of packages using a mix of 2.13 and 2.52 autoconf scripts that need to be modifed. We would also like to tell configure what arch to build for directly while at it (even when not crosscompiling), to avoid the config.guess call. (FYI, crosscompilation in Debian is archived by setting some environment variables, which set the desired host and target archs. These variables are always set, since we don't want packages building for iX86-pc-linux-gnu, for X != 3, just because the build machine is not an old i386; you are crosscompiling if host != build arch). Well, as long as the crosscompilation behaviour is not changed ever again, I will be grateful to you guys. After all, it is not funny to break God-knows-how-many-hundreds-of-packages at every new autoconf release :) So, which behaviour will _really_ be supported, officially, from now on? If autoconf will change that crosscompilation stuff yet again in the future, I would like to know about that officially... so that I can justify a proposal to force all Debian packages to call a wrapper instead of the configure script, or something :( -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
