I don't know the right way to fix this, but something is definitely broken;
and something needs to be fixed, one way or the other. The question is what
exactly needs to be fixed.
Consider something like this:
AC_TRY_LINK_FUNC(res_query, AC_MSG_RESULT(yes), AC_MSG_RESULT(no))
Here's what happens on x86_64:
gcc -o conftest -g -O2 -Wall -I.. -I./.. conftest.c -lresolv >&5
/tmp/ccW7EeDX.o(.text+0x7): In function `main':
/home/mrsam/src/courier/authlib/configure:5160: undefined reference to
collect2: ld returned 1 exit status
configure:5147: $? = 1
configure: failed program was:
[ blah blah blah ]
| /* We use char because int might match the return type of a gcc2
| builtin and then its argument prototype would still apply. */
| char res_query ();
| main ()
| res_query ();
| return 0;
The same exact test on FC1 x86 will work.
The reason appears to be that you have to #include <resolv.conf> on x86_64
in order to succesfully pull res_query() out of libresolv.so. You don't
need to do this on x86, and the test program generated by AC_TRY_LINK_FUNC
does not include any headers, but uses a manual prototype.
So, what now?
Before I start digging in the up2date code myself, maybe someone
can comment on this:
I have a problem when using up2date up2date with my self-created
APT repositories. When updating, it complains about conflicting
files: it just thinks that a long list of directories that are
shared among packages conflict with each other.
Apt-get itself (and synaptic) seems to work fine with the same
repository, only with up2date there is a problem. Also, up2date
with a yum repository of then same package set works fine, as
does yum itself.
FWIW: I generate my APT repositories with --flat --bloat.
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
-----BEGIN PGP SIGNED MESSAGE-----
If I remember Tim Waugh did an rpm for this.
Tim, do you have an updated one or should I take your src.rpm and update it?
T +44 (0) 1224 587369
M +44 (0) 7930 323266
F +44 (0) 1224 742001
Open Source. Open Solutions.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----
Recently the version of libgcrypt was increased to 1.1.94 as a result of
this newpg would not build against the newer libgcrypt i sent an email to
gcrypt-devel list and this is what i got back
Don't build newpg at all. It has been superseded by gnupg-1.9.x .
You would need an old libgcrypt < 1.1.42 to build it. The configure
sscript was not able to detect newer versions with a changed API.
we have a problem here seems we no longer need newpg but we need things it
provides for gpgme gpgme03 cryptplug gpa kgpg (which doesnt complain so
much just says its not there) to get these things it provides we need to
go to the newer gnupg or we need to revert back to the older libgcrypt.
being so late in the cycle i dont know which would be best. so i thought id
ask before filling a bug against something. it does need to be fixed before
final is out as people will complain if they cant decrypt email in kmail or
mutt gpa doesnt work etc. i think we should probably go back to the old
version of libgcrypt
Maybe Suse team will find XFwall of interest.
It is a serious and well tested KDE firewall configuration tool released under GNU/GPL.
StarLink Conectividade Ltda
Acesse nosso portal www.click21.com.br
Porque internet grátis, nem a Embratel pode fazer mais barato. Mas pode fazer melhor.
The roadmap targets 1.0 release for September 14th (one week before
FC3 for October 18th
Since Evolution is the default mail client, perhaps it's time to push
FireFox in Fedora Core and set it as default browser.
Or it's better to wait FireFox 1.0 _and_ Thunderbird 1.0.
Ok, a bit of introduction. Due to some phenomenal eBay buys, I have a fairly
elaborate ATM network here at PARI. I have five 3Com CoreBuilder 7000 5Gbps
switches, a dozen or so dual OC-12 cards, bunches of OC-3 cards, etc.
I have a Dell PowerEdge 1600SC running FC1 with a ForeRunner HE622 OC-12 NIC
installed that is working very well with the linux-atm project's LANE code
(oddly, I can't rebuild from source due to some fancy things a few of the
low-level diag pprograms need from the kernel headers, but since the
linux-atm project provides prebuilt binary RPMs that's not a big issue). I
get good bandwidth through the HE with a LANE LEC set up with the zeppelin,
atmsigd, and ilmid setup as shipped with the linux-atm userland package.
So, I am setting up a second Dell 1600SC with another HE622 card to test the
ATM cloud's performance. This 1600SC is my testbed and is running FC2. So I
install the linux-atm userland, and attempt to use the HE. Well, the .358
kernel doesn't have the HE or any ATM drivers. So I updated to the latest,
and it has CONFIG_ATM unset, too. My question to the kernel maintainers here
(Arjan, Alan, and Dave) is simply 'Why no ATM?' The ATM support is actively
maintained, is production quality, etc.
The second question is 'how do you generate the configs used in the kernel
SRPM' and is that tool available as part of the SRPM? I will be recompiling
with ATM support, but I want to use the Officially Approved rpmbuild
--rebuild kernel-x.y.z-a.b.c.src.rpm method, since I want to distribute this
kernel internally to all machines that will be running ATM cards. I am not
uncomfortable hand-editing the config file, but I know that that is
This of course is the Way to Do It since the desire is to not ship
kernel-sourcecode anymore, so custom kernels have to come from the SRPM,
which is fine by me as long as the configuration tools used to generate those
prepackaged configs are available.
I am looking at system-config-network too for ATM support; I know this is not
a RedHat-supported item, but it is something I will need at some point, since
I want native ATM networking available to some of my users.
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
I have my own build system that is completely written from scratch with the aim
of finding build problems. I have been using the 437 kernel for quite a while and
decided its time to start trying the 2.6.8 rc's. I tried to compile 499 and it
errors out. I haven't found the exact problem, but I did notice that its trying
to do something naughty:
depmod: Can't open /lib/modules/2.4.20-31.9smp/modules.dep for writing
Why would a rpm package build be trying to modify my running system? The build
root is an entirely different path. Should this step be noop'ed or build-root
appended to the path? Do you want this in bugzilla?
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!