jiangtao9999

…………………………
你以为 so 就象 dll 那样哪？？？

linuxpgy

引用:

…………………………
你以为 so 就象 dll 那样哪？？？

of course. They are the Same.

lanzinc

对dll不太了解
dll好象有很多种, 什么OLE COM COM+ 等等的能介绍一下吗

linuxpgy

http://support.microsoft.com/default.aspx?scid=kb;zh-cn;815065
这里说的很详细了~~~

jiangtao9999

so 和 dll 不一样………………
windows 的主要 dll ，是微软随同系统一同发布，且没有源代码，不能更改的………………

linuxpgy

linux的lib hell!!!!!!!!

Under Windows, you have the infamous "DLL hell", where you can have dozens
of different programs which require different versions of the same
third-party DLL with the same name.  This page --
http://www.faqs.org/docs/artu/ch03s02.html -- describes it best:

    Because Windows does not handle library versioning properly, it suffers
    from a chronic configuration problem called "DLL hell", in which
    installing new programs can randomly upgrade (or even downgrade!) the
    libraries on which existing programs depend. This applies to the
    vendor-supplied system libraries as well as to application-specific ones:
    it is not uncommon for an application to ship with specific versions of
    system libraries, and break silently when it does not have them.

Unfortunately, we've seen this under OS/2 as well, with the inability of
Mozilla-based applications to coexist without awkward workarounds.

Unix-based systems like Linux, on the other hand, avoid "DLL hell" by
linking to specific named versions of shared libraries.  Essentially, it
trades it for "lib hell" instead, where every single application can
depend on a different point version of a library, and refuse to run
until a copy of that exact version is hunted down and installed.  When you
have hundreds of programs, each of which can depend on a dozen or more
such libraries, it's enough to turn a person prematurely grey.

It's exacerbated, of course, by Linux's continued adherence to the
fundamental Unix design philosophies, notably "never implement what you
can rely on an existing program or library for".

I just finished assembling a WarpIn install package for the GIMP 2.2.8,
and the number of external libraries it depends on is insane.  (And it's
not even the worst offender by a long shot.)

At least Debian-based Linuxes have an intelligent package management
system that keeps track of all dependencies for you (and offers to
download and install them automatically if it finds them missing).

linuxpgy

autopackag刚刚用了一下，感觉和rpm类似，只是图形化而已，缺少的包还是要自己去下载。
装giam运行结果：
[code:1]
Checking for required C library versions ...  OK
Checking for GTK+ user interface toolkit ...  OK
Checking for Audio File Library ...  OK
Checking for libao cross platform audio library ...  OK
Checking for GtkSpell Spell Checking Library ...  failed

Error: Could not find 'GtkSpell Spell Checking Library'. Try using the native package manager for Mandriva Linux (urpmi) to install a package with similar name to 'gtkspell'.

Error: Unable to prepare package Gaim Internet Messenger.
[/code:1]
等会试试klik

linuxpgy

klik比autopackage聪明多了，就像apt比rpm聪明一样，它会下载所需的deb包装上，自己解决依赖关系，可以试试。 总之一句话，只要上网，依赖关系就可以解决！

关于前几天讨论的自带库的rpm问题，现在我有了新的想法。跨发行版安装基本不行，（有些极端的手段也许可以，但是问题很多）。二进制层兼容性很差。不像windows只有一家在发行系统二进制库，linux的发行版太多了(据说有386个。。)，编译环境，库的版本（linux lib hell）都不一样，这里运行好好的程序拿到另一个系统就有问题。

linux什么时候才能统一呢？如果只有一个linux发行版，一种桌面环境，就不用考虑跨发行版带来的种种问题，那样的话安装一个新软件会容易的多。。 :neutral:

KDE

[quote:68b74396c7="linuxpgy"]klik比autopackage聪明多了，就像apt比rpm聪明一样，它会下载所需的deb包装上，自己解决依赖关系，可以试试。 总之一句话，只要上网，依赖关系就可以解决！

关于前几天讨论的自带库的rpm问题，现在我有了新的想法。跨发行版安装基本不行，（有些极端的手段也许可以，但是问题很多）。二进制层兼容性很差。不像windows只有一家在发行系统二进制库，linux的发行版太多了(据说有386个。。)，编译环境，库的版本（linux lib hell）都不一样，这里运行好好的程序拿到另一个系统就有问题。

linux什么时候才能统一呢？如果只有一个linux发行版，一种桌面环境，就不用考虑跨发行版带来的种种问题，那样的话安装一个新软件会容易的多。。 :neutral:[/quote]
绕了一圈，你终于明白了，可喜可贺。

jiangtao9999

解决的最好办法就是提供从源代码编译！

linuxpgy

原代码编译？
首先，并不是每个人都装了gcc，及所有编译所需的sdk,其次，不是每个人都是编程狂人，能应对编译错误，再次，不是每个人都能忍受漫长的编译时间……所以这种方法不适合普通用户。

既然magic也是基于rpm管理的，rpm不能跨平台，所以为这个平台打包的软件必须丰富起来，不然要装anjuta之类的还需要其他发行版的包。有个非官方的软件包，做的很不错，如果有更多适合magic的rpm就好了。   所以我觉得magic应该在做rpm上加大力度，系统的升级可以慢一点，平时补丁打打就好了，这样我相信magic会成为中国唯一的linux的。

magic也有apt源，不知道里面有什么软件，里面很多吗？

jiangtao9999

开发人员数量决定软件包的数量…………

ququ01

我有个问题  急盼回复   这是我的SPEC

ummaryhotoDVD is a very sample application which enables you to create and burn photos slideshow to DVD.

Name: PhotoDVD

Version: 1.0

Release: 1mgc

Copyright: Commercial

Group: Graphics

Source0:%{name}-%{version}.tar.gz

%description
PhotoDVD helps you use DVD or CD burner to create photo album on DVD disc playable on TV with background music, a lot of pictures, transition effects.
%prep
#tar xzvf $RPM_SOURCE_DIR/%{name}-%{version}.tar.gz -C $RPM_BUILD_DIR/

%setup -n %{name}-%{version}
%build

%install
mkdir  /Colorlife
mkdir -p /EB_Workshop/EB_Dependence

cd $RPM_BUILD_DIR/%{name}-%{version}

cp -R Lib /EB_Workshop/EB_Dependence
cp -R MainconCeptLib/*  /usr/lib
cp -R sharedlib/* /usr/lib
cp -R PhotoDVD /Colorlife

%clean
rm -rf $RPM_BUILD_DIR/PhotoDVD

%files
%defattr(-,root,root)
/Colorlife/PhotoDVD/
/usr/lib/libipp*.so
/usr/lib/libmcmpgvout.001
/usr/lib/libmcmpgvout.002

%changelog


然后我　rpmbuild -ba PhotoDVD-1.0-1.spec

生成的PhotoDVD-1.0-1mgc.i386.rpm　　
两个问题
我在干净的环境中第一次运行　程序总是报错　启动不了．
２．我在另一台机器下安装，根本就没有ＣＰ

linuxpgy

错误信息是什么？详细一点

KDE

to： ququ01
1、你根本就没有仔细阅读 rpm 建包原理，严重违反了一些基本建包原则。
2、你在 %files 丢了东西，难道你在执行 rpmbuild -ba PhotoDVD-1.0-1.spec 就不看看错误输出么？
3、我们不会对不开源的商业软件提供任何额外的无偿 rpm 建包技术支持。现有文献就是你最好的学习资料。