autotools

I

irkkaaja

How do I change the default paths for the storage of libraries and headers to include /usr/local/lib and /usr/local/include, because when autoconfiguration tools attempt to compile software for me they can find headers and libraries in /usr/lib and /usr/include but not in the /usr/local/ subdirectories, which is a massive pain.

I mean you'd think the system would be set up with the default storage of the ports tree in mind, but noooooo...
 
irkkaaja said:
I mean you'd think the system would be set up with the default storage of the ports tree in mind, but noooooo...
Click to expand...

Well actually that's exactly what happens. I'm sure if you bothered to think about it for second, you'd understand that as well. Basically the entire FreeBSD uses the ports system for nearly every install and if problems were as systemic as you claim, I'll go out on a limb here and state similar problem reports/complaints would be widespread.

Now that we have that cleared up, why don't you start with the specific issue you are having instead of made up problem FreeBSD infrastructure.
 
Galactic_Dominator said:
Well actually that's exactly what happens. I'm sure if you bothered to think about it for second, you'd understand that as well. Basically the entire FreeBSD uses the ports system for nearly every install and if problems were as systemic as you claim, I'll go out on a limb here and state similar problem reports/complaints would be widespread.

Now that we have that cleared up, why don't you start with the specific issue you are having instead of made up problem FreeBSD infrastructure.
Click to expand...
Okay, smart guy, explain this:
Code: 
johnny# ./configure
[...]
checking for gsm_create in -lgsm... no
error: cannot find libgsm: Is it installed? Also make sure you have the
       libgsm development packages installed.
exit: Illegal number: -1
johnny# ln -s /usr/local/lib/libgsm.a /usr/lib/libgsm.a
johnny# ln -s /usr/local/lib/libgsm.o /usr/lib/libgsm.o
johnny# ln -s /usr/local/lib/libgsm.so /usr/lib/libgsm.so
johnny# ln -s /usr/local/include/gsm.h /usr/include/gsm.h
johnny# ./configure
[...]
checking for gsm_create in -lgsm... yes
checking gsm.h usability... yes
checking gsm.h presence... yes
checking for gsm.h... yes
[...]
You notice the part where it doesn't work when it clearly should, and then it does work when some libraries are moved from one perfectly valid location -- and in fact the default location where ports are -- to another perfectly valid location, and then it works just fine, and you're telling me that there isn't a problem with things being configured so as not to recognize something stored in a perfectly valid location?

Perish the thought!

Now maybe reread the post and focus on the actual problem, not the whine at the end, because the default configuration of FreeBSD isn't my problem: my problem is that it's a pain in the ass to compile Mangler.
 
irkkaaja said:
it's a pain in the ass to compile Mangler.
Click to expand...

You mean audio/mangler?

"./configure" is not going to use the port infrastructure, it won't know about it. So paths to includes could easily be missing. The ports version is to cd to the port directory (/usr/ports/audio/mangler/) and use
# make configure

If you're trying to use a newer version than the port, it's often easier to just update the port than to build from raw source.

Incidentally, be sure to delete those library links so they don't stick around to haunt you. Which is not to say that you'd ever see a problem, just if you do it would be mystifying and potentially difficult to solve.
 
If you're using the ports infrastructure, you should use the ports infrastructure instead of making up rules how it should work. If you dig into a port's Makefile you'll see there is a lot of magic going there including variable initialization and settings various path's as well as sourcing a lot of port logic files. You would need to accomplish at least some of those things in your environment in order for a configure script to pick up the appropriate paths. Or just use ports() where some nice people have already done that and other work for you.
 
The mangler port crashes whenever I try to connect to a server, which is why I was compiling the source package from the site. The same problem arises, though, whenever I try to do this with anything, not just Mangler. IUP is equally a pain.

The problem is that some environment variable is configured by default so that if I type:

Code: 
gcc -lgsm

without including the extra flag -L/usr/local/lib, it will not find /usr/local/libgsm.so. That is to say: the gsm libraries are installed, and I cannot link them without additionally specifying where they are, which is not how things should work. It's controlled by some environment variable like LD_LIBRARY_PATH or somesuch and honestly I don't know where to find that information.

I don't care what the default LD_LIBRARY_PATH or whatever is. I want to know how to change it. And I don't want other people to assume I didn't look in the ports collection for the software I'm trying to install. I'm not an idiot.

If you're using the ports infrastructure, you should use the ports infrastructure instead of making up rules how it should work.
Click to expand...

Look, if you don't know how to solve my problem, just don't post. Ports doesn't include all the software in the universe. I want ./configure to work. I will not consider the problem "solved" until I know how to make ./configure work. Period. Okay?

:/
 
So your real question could be "What's the proper way to upgrade a port?"
which is going to be something like this:
1. portsnap fetch update
2. Review /usr/ports/UPDATING for any relevant issues.
3. Using a ports management tools of your choice like portmaster(8) to upgrade the specific port which will automatically pull in any dependencies which are also out of date.

The original question could also have been better if it was in the form of "Program X crashes when I do this. Here are my install specs."
 
Galactic_Dominator said:
So your real question could be "What's the proper way to upgrade a port?"
which is going to be something like this:
1. portsnap fetch update
2. Review /usr/ports/UPDATING for any relevant issues.
3. Using a ports management tools of your choice like portmaster() to upgrade the specific port which will automatically pull in any dependencies which are also out of date.

The original question could also have been better if it was in the form of "Program X crashes when I do this. Here are my install specs."
Click to expand...

No, the problem is that ./configure doesn't work.

Seriously, just stop posting. I don't know whether you actually think you're helping or you're just trying to insult me, but if you're not going to explain how the linker works and how to make it do what I want, then don't post irrelevant shit about using the ports collection. I know how to use the ports collection, it's in the handbook.
 
What I did:

Posted a thread asking how to use autotools on a forum about FreeBSD. I mean, what?

What I should have done:

Code: 
johnny# ./configure --help
[a bunch of nonsensical jibberish]
Some influential environment variables:
  CXX         C++ compiler command
  CXXFLAGS    C++ compiler flags
  [b]LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
              nonstandard directory <lib dir>[/b]
  LIBS        libraries to pass to the linker, e.g. -l<library>
  [b]CPPFLAGS    (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
              you have headers in a nonstandard directory <include dir>[/b]
  CC          C compiler command
  CFLAGS      C compiler flags
  CPP         C preprocessor
  CXXCPP      C++ preprocessor
  PKG_CONFIG  path to pkg-config utility
  speex_CFLAGS
              C compiler flags for speex, overriding pkg-config
  speex_LIBS  linker flags for speex, overriding pkg-config
  celt_CFLAGS C compiler flags for celt, overriding pkg-config
  celt_LIBS   linker flags for celt, overriding pkg-config
  x11_CFLAGS  C compiler flags for x11, overriding pkg-config
  x11_LIBS    linker flags for x11, overriding pkg-config
  xi_CFLAGS   C compiler flags for xi, overriding pkg-config
  xi_LIBS     linker flags for xi, overriding pkg-config
  gtk_CFLAGS  C compiler flags for gtk, overriding pkg-config
  gtk_LIBS    linker flags for gtk, overriding pkg-config
  dbus_CFLAGS C compiler flags for dbus, overriding pkg-config
  dbus_LIBS   linker flags for dbus, overriding pkg-config
  gtkmm_CFLAGS
              C compiler flags for gtkmm, overriding pkg-config
  gtkmm_LIBS  linker flags for gtkmm, overriding pkg-config
  pulse_CFLAGS
              C compiler flags for pulse, overriding pkg-config
  pulse_LIBS  linker flags for pulse, overriding pkg-config
  alsa_CFLAGS C compiler flags for alsa, overriding pkg-config
  alsa_LIBS   linker flags for alsa, overriding pkg-config
  gthread_CFLAGS
              C compiler flags for gthread, overriding pkg-config
  gthread_LIBS
              linker flags for gthread, overriding pkg-config

Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.

Report bugs to <eric@ypass.net>.

And it works:

Code: 
johnny# export LDFLAGS=-L/usr/local/lib
johnny# export CFLAGS=-I/usr/local/include
johnny# ./configure
[a bunch of nonsensical jibberish]

...and then all was right with the world.
 
You must log in or register to reply here.
Back
Top