Re: version numbers needed for preprocessors / libsf_engine?

[Steven Sturges <steve.sturges () sourcefire com>]

Markus Lude wrote:
> On Tue, Dec 29, 2009 at 03:18:38PM -0500, Steven Sturges wrote:
> > Hi Markus--
>
> Hello Steven,
>
> > Are you talking about the version number on the .so itself,
> > or the version/build numbers that are internal to the code?
>
> I'm talking about the "version" in the filename.
>
> > The internal version numbers were intended to help in handling
> > compatibility problems, but it is best to replace both the
> > shared libs and Snort together.
> >
> > Generally, when I build/install the .so's, the plain .so actually
> > gets symlink'd to a similarly named file that has a version.
>  
> On OpenBSD we don't have those symlinks.
>
> My problem at the moment is the following:
>
> So far I used
>
>   dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.so
>
> in snort.conf, even when the file actually was for example
> libsf_engine.so.3.0. With the changes in 2.8.5 regarding looking after
> the libs I now either need to add the correct version number to the
> configuration line or change it to
>
>   dynamicengine directory /usr/local/lib/snort_dynamicengine/

I'd opt for this approach -- using the directory name -- versus
specifying the specific filename from the default config.

So long as the install doesn't dump preprocessors, the engine,
and .so rules into the same directory, that will work.

It seems that would be much more portable and I often kick myself
for not doing that initially with the engine anyway.  ;)

> If I simply drop the version number from the file name my old settings
> could still be used and one don't need to adjust the version number with
> every update.
>
> As I'm not that familiar I'm unsure if one could simply add
> "-avoid-version" e.g. to libsf_engine_la_LDFLAGS in case of sf_engine or
> libsf_ftptelnet_preproc_la_LDFLAGS in case of the ftptelnet
> preprocessor in the Makefiles.

Not sure on this in terms of how portable that flag is... It might
depend on the linker being used.

> Hmm, another thing: I didn't find the place for doing the above for the
> two example libs or where best to disable the build of them. I think
> those aren't really needed in a package. Or am I wrong here?

No, those are only there as reference implementations, but they
need to be included in source distros, so that's why they are
referenced in configure.in & the top level Makefile.am.

Probably the best way to eliminate from the build right now is to
remove the references to dynamic-examples from configure.in and top
level Makefile.am.

We could look into having a --enable-build-examples or something that
causes them to get built, defaulting to off.

> Regards,
> Markus

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel