Lets see, that means you are not yet using glibc-2.11.1 and gcc-4.4.2, right?

This is what I got when running src2pkg --setup:

However, I did run src2pkg on a huludesktop rpm with absolutely no problems. It seemed to work just fine. The package installed and works just fine.

I'm still with src2pkg 1.9.9. It's working fine where in my slackware 13 64 bits with updates until 19Dez.
This the slackware that I use to work. I have another partition with slackware 13 64 bits current (updated), but its only for experimental use.

The problem starts with the next update (Jan 4) in current after Dec 19, when the whole toolchain gets updated.

I'm with 13 - 64bits current from Dec 19 and received that error in tar

Hi,

A belated Happy New Year and thank you for src2pkg.

I'm using both Slackware 13.0 32- and 64-bit and have the same problem on both building netcdf-3.6.3 (http://www.unidata.ucar.edu/download..._6_3/index.jsp). netCDF is required by The Generic Mapping Tools (GMT) (http://gmt.soest.hawaii.edu). I install both in /opt so they're completely stand-alone; i.e., executables, libraries, documentation and stuff are not spread all over the system.

It seems that src2pkg ignores --exec-prefix for the library installation path but honors it for documentation, manuals, info and other stuff. Hmm.

So, what I had to do was
to get stuff installed where I wanted it to; i.e., I had to explicitly include the --libder= argument (the executables, docs and all that got put where they were supposed to be, apparently with --exec-prefix).

Did I miss something?

Thanks again for src2pkg

P.S. I'm not trying to build GMT as a package (yet) -- it's a little on the complicated side what with all the geographic data sets that need to be installed. That'll be next week...

I don't really see a better way to deal with that than what you've done. src2pkg doesn't do anything specifically with 'exec-prefix'. It's libdir that it deals with in an automatic fashion -as a way of allowing the same script to be used for both 32 and 64-bit builds without having to specify libdir in the options at all. It *does* check to see if you have specified libdir, though and doesn't arbitrarily set it if you have.

The only other alternative would be to never set libdir at all -which means you'd have to include it in the options more often -not always, but more often. The automatic setting of libdir could be done away with, but i think it would break more builds than it would fix. As it is, it nearly always does the Right Thing automatically, unless you explicitly set it. But, I'll definitely give this some thought -it probably should be basing its' automatic location on the value for prefix (or exec-prefix), but currently just does what is the most normal thing. I have looked at this before, because some configure scripts (or other build systems like rpm) use 'libdir' and 'usrlibdir', 'bindir' and 'usrbindir', etc.

At least you can be glad that I did think it through enough to not set libdir if you have already given it. I'll chew on this some more and see what I come up with. Thanks for bringing it up.

Thanks for the thoughts and, mostly, I agree but... I build non-system software; i.e., software that is not a part of Slackware, to install in the /usr/local or /opt trees. I've just never liked the idea of installing add-on software in system directories simply because it's too easy to get burned that way. So, if I build something with, say, src2pkg I'll want all of it to install in the /usr/local tree if I set --prefix=/usr/local (or just let it default for most "configure-make-make install" software).

I just remember a two-long-long-day bug finding session when somebody (twern't me!) installed a package (on a Sun production server) that just happened to have a library with the same name as a system library (we all know that that never happens, eh?) and it took too many guys too much effort for too long a time to find out why applications were blowing up. That may not be the best reason for isolation installation but it sure feels right to me -- once burned, three times shy or something like that. Never had any similar problems since.

Anyway, now that I know I'll just add the extra option when I build stuff.

Thanks again.

I am going to look at this today -it does make sense to follow the prefix or exec-prefix directives. As for using prefix=/usr/local, src2pkg is already *supposed* to trun of lots of arbitrary actions when you use it. And the libdir setting should follow that.

You really should save and use a build script for builds like that, where you add extra options:
src2pkg -N \
-p=/opt/netcdf-3.6.3 \
-e='--exec-prefix=/opt/netcdf-3.6.3 \
--libdir=/opt/netcdf-3.6.3/lib \
--enable-shared \
--enable-docs-install' \
netcdf-3.6.3.tar.gz
will create it for you. Then you can simply run:
src2pkg -X -C -A -DEST
to execute it.

Okay, I've looked at this again. It actually is doing the Right Thing by default. If you are building packages which do not use --prefix=/usr, the best thing to do is to set:
FHS_POLICY=NONE
either from the command-line:
FHS_POLICY=NONE src2pkg ...
or in your src2pkg.conf file:
[[ $FHS_POLICY ]] || FHS_POLICY=NONE

By doing that, then everything will work as expected. Your example build can be done simply like this:
FHS_POLICY=NONE src2pkg -p=/opt/netcdf-3.6.3 -e='--enable-shared --enable-docs-install' netcdf-3.6.3.tar.gz

If you want to understand the FHS_POLICY option more, have a look at the code around lines 883-988 in /usr/libexec/src2pkg/01-pre_process.

Gilbert,

You know, every time I use src2pkg I'm more impressed -- you have done a job of work, sir (and I need to spend some time carefully reading the documentation!).

I rebuilt netCDF with FHS_POLICY=NONE as you've indicated, everything installed in /opt, and I am a happy, happy camper.

Wow, zowie.

Thanks,

Thomas

Still having problems

Going back to 1.9.9.

Laodiceans, I'm going to upload a new version in a little while, but perhaps it would be good if you tested it first. I mailed a copy to a couple of people 2-3 days ago, but there was still one un-fixed problem on 64-bit, but tar-1.13 was fixed.
Did I get an email from you before? Please shoot me an email and I'll send you a copy of what I'm about to upload.

I went ahead and uploaded the new version as the testers all reported success over the lastfew days. Hopefully everything is fixed now...

Thank you, gnashley! :) Downloading, upgrading now.