[Bro-Dev] #402: [PATCH] -fPIC is needed for FreeBSD/amd64
bro at tracker.icir.org
Tue Apr 12 11:41:33 PDT 2011
#402: [PATCH] -fPIC is needed for FreeBSD/amd64
Reporter: leres | Owner: jsiwek
Type: Problem | Status: assigned
Priority: Normal | Milestone:
Component: Broccoli | Version: git/devel
Resolution: | Keywords:
Comment (by jsiwek):
> I just tried grabbing a fresh copy of git://git.bro-ids.org/broccoli
and building with --enable-static and --enable-shared (7.2-RELEASE and
8.2-RELEASE, both amd64) and [cut] I no longer see any errors from either
build. So something has changed since in the way broccoli is being built
between now and when I filed this ticket.
I think you are probably not building the python bindings now, but were
not before. If you clone the broccoli repository recursively, the python
bindings code is present and automatically built by default. If you clone
non-recursively, then the binding's source code doesn't exist and it just
skips building them with a warning. The error in this ticket specifically
happens when linking the bindings module on x86_64 to a static broccoli
library, so you won't see the error if you're just building the main
I was able to reproduce the error yesterday, so I still want to do
something to address it.
> Since the 1.5.3 version of Broccoli builds both shared and static
libraries by default on FreeBSD amd64 without issue I think it's
ridiculous that the new cmake version can't.
Again, I think the confusion is whether the broccoli python bindings are
being built or not (In 1.5.3, I think the behavior is to only build them
when installing broctl, linking them against the shared libbroccoli)
> there doesn't appear to be a way to build both static and shared
libraries at the same time (why not??)
There is a CMake limitation that a given build target can't be both STATIC
and SHARED during the same configuration/build. See:
However, I think what I want to try is specifying two distinct build
targets, one each for STATIC and SHARED. Then they can both be built by
default and I'll prefer to link the broccoli python bindings against the
SHARED version, for which this error will never occur.
> Needing to link the broccoli bindings against a static broccoli library
> be a common situation that users will find themselves in.
> I think there's a big difference between that and disallowing the user
to build both.
I think there's a difference between "disallowing" and "not working by
If I do the "two build targets" approach, all the common configurations
should work by default with no user action necessary. The one that will
not work by default on x86_64 is:
# when configuring broccoli with bindings present
but the user can add the right `-fPIC` option to get it to work (if
they're really sure that linking broccoli statically into the bindings is
what they want to do).
> BTW, is there magic to coerce cmake into to showing the actual gcc
lines? "Building C object" is nice when things work but it isn't so
helpful when things don't.
Ticket URL: <http://tracker.icir.org/bro/ticket/402#comment:7>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker
More information about the bro-dev