|Summary:||ppp plugins don't respect CC CFLAGS LDFLAGS|
|Product:||Gentoo Linux||Reporter:||Harald Schioeberg <schioebe>|
|Component:||New packages||Assignee:||Gentoo Dialup Developers <net-dialup>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Harald Schioeberg 2006-05-03 05:26:08 UTC
ppp pugins don't respect CC CFLAGS LDFLAGS (confirmed with 2.4.2-r15 and 2.4.3-r14) this especially prevents crosscompiling ppp with dhcp support (don't know if other USE flags are also affected) reason: /var/tmp/portage/ppp-2.4.3-r14/work/ppp-2.4.3/pppd/plugins/Makefile.linux these are the first lines of this file: CC = gcc COPTS = -O2 -g CFLAGS = $(COPTS) -I.. -I../../include -fPIC LDFLAGS = -shared [...] and it simply does not respect any environment variables, especially it neglects CC=<arch>-<vendor>-linux-<libc>. The main reason is, of course, the lack for autoconf support, but unless the upstream changes this, this Makefile needs a patch to test for existing CC CFLAGS LDFLAGS.
Comment 2 Alin Năstac (RETIRED) 2006-05-03 21:32:11 UTC
I will fix it like this: #CC = gcc COPTS = -O2 -g CFLAGS += $(COPTS) -I.. -I../../include -fPIC LDFLAGS += -shared Does this change make net-dialup/ppp cross-compilable?
Comment 3 solar (RETIRED) 2006-05-04 04:56:40 UTC
Alin, that should be fine.
Comment 4 solar (RETIRED) 2006-05-04 05:01:10 UTC
actually that would force the -O2 -g after the users cflags nullifing the users desired flags? Looks like it to me. I'd remove the default value of the COPTS= unless pppd is known to be buggy otherwise.
Comment 5 Harald Schioeberg 2006-05-04 05:18:18 UTC
just my 2 cents, thats all untested and written from scratch in the browser: I would do a CFLAGS += -I.. -I../../include -fPIC and comment COPTS out, the user is supposed to add -O and -g flags to make.conf's CFLAGS if he wants them, and i assume it's harmless not to have them. for LDFLAGS: the cleaner way would be to respect the "static" USE flag, but then you might need something like #ifdef USE_STATIC LDFLAGS += -static PLUGINS := minconn.a passprompt.a passwordfd.a #else LDFLAGS += -shared PLUGINS := minconn.so passprompt.so passwordfd.so #endif %.a: %.c $(CC) -o $@ $(LDFLAGS) $(CFLAGS) $^ Maybe one must leave -fPIC out for the static linking. Maybe this draws a lot of similar changes to all the other Makefiles along, but that might allow to build a static linked pppd. If you are on the way updating the the Makefile you could also do #ifdef USE_RADIUS SUBDIRS += radius #endif (maybe you need to add radius to the used USE flags, maybe it breaks everything)
Comment 6 Harald Schioeberg 2006-05-04 05:27:54 UTC
forgot to mention: this bug orgiginates from this thread on gentoo-embedded: http://thread.gmane.org/gmane.linux.gentoo.embedded/588/focus=588
Comment 7 Torsten Veller (RETIRED) 2006-05-04 09:01:47 UTC
(In reply to comment #0) > /var/tmp/portage/ppp-2.4.3-r14/work/ppp-2.4.3/pppd/plugins/Makefile.linux > > these are the first lines of this file: > > CC = gcc > COPTS = -O2 -g > CFLAGS = $(COPTS) -I.. -I../../include -fPIC > LDFLAGS = -shared > [...] Please confirm that this is not true. Rerun 'ebuild /usr/portage/net-dialup/ppp/ppp-2.4.3-r14.ebuild clean unpack` (It might be true for ~ppp-2.4.2) Here it is: | head -n2 /var/tmp/portage/ppp-2.4.3-r14/work/ppp-2.4.3/pppd/plugins/Makefile.linux | CFLAGS = $(COPTS) -I.. -I../../include -fPIC | LDFLAGS = -shared
Comment 8 Harald Schioeberg 2006-05-04 09:32:57 UTC
> > Please confirm that this is not true. Rerun 'ebuild > /usr/portage/net-dialup/ppp/ppp-2.4.3-r14.ebuild clean unpack` > > (It might be true for ~ppp-2.4.2) > > Here it is: > | head -n2 > /var/tmp/portage/ppp-2.4.3-r14/work/ppp-2.4.3/pppd/plugins/Makefile.linux > | CFLAGS = $(COPTS) -I.. -I../../include -fPIC > | LDFLAGS = -shared > confirmed. i don't know why i got a 2.4.2 Makefile in the 2.4.3 tree, thats my fault. The problem remains, it is only another file: USE="$USE dhcp" ebuild /usr/portage/net-dialup/ppp/ppp-2.4.3-r14.ebuild clean unpack /var/tmp/portage/ppp-2.4.3-r14/work/ppp-2.4.3/pppd/plugins/dhcp/Makefile.linux reads: [..] dhcpc.so: dhcpc.o clientpacket.o packet.o socket.o options.o gcc -o dhcpc.so -shared dhcpc.o clientpacket.o packet.o socket.o options.o [..] I'm really really sorry for the confusion.
Comment 9 Torsten Veller (RETIRED) 2006-05-04 09:51:50 UTC
(In reply to comment #8) > The problem remains, it is only another file: > > USE="$USE dhcp" ebuild /usr/portage/net-dialup/ppp/ppp-2.4.3-r14.ebuild clean > unpack > /var/tmp/portage/ppp-2.4.3-r14/work/ppp-2.4.3/pppd/plugins/dhcp/Makefile.linux > reads: > [..] > dhcpc.so: dhcpc.o clientpacket.o packet.o socket.o options.o > gcc -o dhcpc.so -shared dhcpc.o clientpacket.o packet.o socket.o > options.o > [..] > That's what i've fixed yesterday. Please resync. So what remains are some missing LDFLAGS at various places. -*- 'static': I guess it doesn't make sense to build the plugins static. "Starting with version 2.3.10, pppd includes support for `plugins' - pieces of code which can be loaded into pppd at runtime and which can affect its behaviour in various ways. The idea of plugins is to provide a way for people to customize the behaviour of pppd without having to either apply local patches to each version or get their patches accepted into the standard distribution. A plugin is a standard shared library object, typically with a name ending in .so. They are loaded using the standard dlopen() library call, so plugins are only supported on systems which support shared libraries and the dlopen call. At present pppd is compiled with plugin support only under Linux and Solaris." (from PLUGINS) -*- 2.4.2 vs 2.4.3: mrness, when will 2.4.3 go stable? It depends on baselayout, doesn't it? Should we patch 2.4.2 too?
Comment 10 Alin Năstac (RETIRED) 2006-05-04 11:04:45 UTC
(In reply to comment #9) > -*- 2.4.2 vs 2.4.3: > > mrness, when will 2.4.3 go stable? It depends on baselayout, doesn't it? Should > we patch 2.4.2 too? Although baselayout-1.12 isn't (and cannot be) in RDEPEND, the 2.4.3 version don't install a /etc/init.d/net.ppp0 script - users should instead use the generic PPP suport available in the forementioned baselayout version. ppp-2.4.3 stableness depends only by the status of baselayout-1.12. If it becomes stable, the next minute after I hear the good news, ppp-2.4.3 will be stable on amd64 and x86. Static plugins makes no sense whatsoever. Now about the best solution to the problem. gestef sent to me on private a solution proposal which I think would be best: CC ?= gcc CFLAGS += -g -I.. -I../../include -fPIC LDFLAGS += -shared Note the forced -g. I think it is apropriate since ppp ebuild don't have a debug USE flag. Also, even if it is somehow difficult to patch such an over-patched package, I still prefer to do those modifications through patch instead sed. It will make a future upstream inclusion much more easy. Thoughts anyone?
Comment 11 Alin Năstac (RETIRED) 2006-05-04 11:20:58 UTC
Ah, my mistake. -g should be removed, not forced.
Comment 12 SpanKY 2006-05-05 17:00:21 UTC
CFLAGS has nothing to do with the debug USE flag
Comment 13 Alin Năstac (RETIRED) 2006-05-07 15:31:52 UTC
fixed in 2.4.3-r15. Basicaly I've renamed the ppp_flags.patch as make-vars.patch and fixed all CFLAGS, LDFLAGS, COPTS, -shared, etc. of the Makefile.linux files found in the package. dhcp-make-vars.patch is the applied to dhcp plugin. Since the old patch already commented some of the CC definitions, I walked on that direction doing the following: - CC commented out - COPTS used as user CFLAGS - LDFLAGS used on all linkage commands - LDFLAGS += -shared in plugins/Makefile.linux I think I've solved all the issues but more pairs of eyes couldn't hurt. Please review the patches/results and, if you discover something, reopen this bug.