User Feedback :: Package names/versions?



Shouldn't the package list be updated as each new release comes out?

Anyway, I am trying to recompile mpg321 with a streaming music info patch (Allows me to get Shoutcast info out of it like I am with VLC) and I ran into some problems. First, when running mpg321's ./configure, I kept getting GCC can not create Excecutable errors. This, and every other problem I got to where because LD could not find the correct library name (libgcc_s, libmad, libao, libdl, libid3tag) because they were not all named correctly (for mpg321, the names had to be the lib*.so, not lib*.so.n) GCC's lib was libgcc_s.so.0, etc. Fixed with a quick symbolic link.

That took me hours to figure out (Some because of my own fault with "find" and linking wrong and etc).

Anyway, I still wasn't able to make, giving me countless errors, but when I looked at it today (I'm compiling the same version of mpg321 that DSL 3.4.x has, without the patch first) and I figure out it is because some /usr/include/ files are missing. Mainly ao.h, mad.h and id3tag.h.

I have gotten mad.h and id3tag.h from the sources, but I was only able to do that because I ran "strings /usr/lib/libmad.so" and got the version number from that (0.15.0b)

What I need is the version number of LibAO that dsl 3.4.x uses.

Also, why did DSL go with Mad .15.0b when 0.15.1b is the last release?

Ohh, and .3 is also in mpg321's cvs. Anyone want a compiled version after this?
Well, the "compiler can't create executables" is result from the freedom to choose your C compiler; the CC variable is not set to anything. Set it to gcc if you want to use the Gnu C compiler..

For the package list, it dates back to very early DSL, and I think it was generated by dpkg. It doesn't have the latest version info, nor all the packages..

The missing headers are due to the gcc extension, I guess they weren't considered important back then, can't speak for the creator though.
For the mad version, the one that was available back then was used.
Quote
Anyway, I still wasn't able to make, giving me countless errors, but when I looked at it today (I'm compiling the same version of mpg321 that DSL 3.4.x has, without the patch first) and I figure out it is because some /usr/include/ files are missing. Mainly ao.h, mad.h and id3tag.h.

I have gotten mad.h and id3tag.h from the sources, but I was only able to do that because I ran "strings /usr/lib/libmad.so" and got the version number from that (0.15.0b)

What I need is the version number of LibAO that dsl 3.4.x uses.


- I could look at adding the appropriate headers/libs to compile-3.3.5.uci if there is a need and if the appropriate version numbers could be confirmed?
Quote (curaga @ Jan. 06 2008,06:59)
Well, the "compiler can't create executables" is result from the freedom to choose your C compiler; the CC variable is not set to anything. Set it to gcc if you want to use the Gnu C compiler..

For the package list, it dates back to very early DSL, and I think it was generated by dpkg. It doesn't have the latest version info, nor all the packages..

The missing headers are due to the gcc extension, I guess they weren't considered important back then, can't speak for the creator though.
For the mad version, the one that was available back then was used.

Well, it wasn't that the CC variable wasn't set. The mpg321 ./configure already knew/wanted gcc. It was that it/ld couldn't find the correct lib by its existing name. So symlink libgcc_s.so.2 to libgcc_s.so worked. Same worked for every other lib that the ./configure was getting an error on.

Now the headers not being included, thats understandable. They are only needed if you are compiling something that requires those libs/headers. For that, I just found the source packages and copied the headers to /usr/include/

It is just that with a up-to-date package list of already installed programs/libs would reduce the amount of guesswork in compiling for already installed libs, and mean that more submitted dsl packages are bound to work.

original here.