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)
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.
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?
Alin, that should be fine.
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.
just my 2 cents, thats all untested and written from scratch in the
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
for LDFLAGS: the cleaner way would be to respect the "static" USE flag,
but then you might need something like
LDFLAGS += -static
PLUGINS := minconn.a passprompt.a passwordfd.a
LDFLAGS += -shared
PLUGINS := minconn.so passprompt.so passwordfd.so
$(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
SUBDIRS += radius
(maybe you need to add radius to the used USE flags, maybe it breaks
forgot to mention:
this bug orgiginates from this thread on gentoo-embedded:
(In reply to comment #0)
> 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
> 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
> | CFLAGS = $(COPTS) -I.. -I../../include -fPIC
> | LDFLAGS = -shared
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
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.
(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
> 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
That's what i've fixed yesterday. Please resync.
So what remains are some missing LDFLAGS at various places.
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?
(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.
Ah, my mistake. -g should be removed, not forced.
CFLAGS has nothing to do with the debug USE flag
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.