[Bro-Dev] #402: [PATCH] -fPIC is needed for FreeBSD/amd64

[Bro Tracker]

#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
 broccoli library.

 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:

 http://www.cmake.org/pipermail/cmake/2005-August/007030.html
 http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_library

 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
 should not
 > 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
 default" :)

 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
 ./configure --disable-shared
 }}}

 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.

 `make VERBOSE=1`

-- 
Ticket URL: <http://tracker.icir.org/bro/ticket/402#comment:7>
Bro Tracker <http://tracker.icir.org/bro>
Bro Issue Tracker